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Abstract 

Multiple  inheritance  has  long  been  plagued  with  the  “diamond”  inheritance  problem,  leading 
to  solutions  that  restrict  expressiveness,  such  as  mixins  and  traits.  Instead,  we  address  the  dia¬ 
mond  problem  directly,  considering  two  difficulties  it  causes:  ensuring  a  correct  semantics  for 
object  initializers,  and  typechecking  multiple  dispatch  in  a  modular  fashion — the  latter  prob¬ 
lem  arising  even  with  multiple  interface  inheritance.  We  show  that  previous  solutions  to  these 
problems  are  either  unsatisfactory  or  cumbersome,  and  suggest  a  novel  approach:  supporting 
multiple  inheritance  but  forbidding  diamond  inheritance.  Expressiveness  is  retained  through 
two  features:  a  “requires”  construct  that  provides  a  form  of  subtyping  without  inheritance  (in¬ 
spired  by  Scala  [39]),  and  a  dynamically-dispatched  “super”  call  similar  to  that  found  in  traits. 
Through  examples,  we  illustrate  that  inheritance  diamonds  can  be  eliminated  via  a  combina¬ 
tion  of  “requires”  and  ordinary  inheritance.  We  provide  a  sound  formal  model  for  our  language 
and  demonstrate  its  modularity  and  expressiveness. 


1  Introduction 


Single  inheritance,  mixins  [12,  5,  24,  22,  4,  9],  and  traits  [19,  23,  39]  each  have  disadvantages: 
single  inheritance  restricts  expressiveness,  mixins  must  be  linearly  applied,  and  traits  do  not  al¬ 
low  state.  Multiple  inheritance  is  one  solution  to  these  problems,  as  it  allows  code  to  be  reused 
along  multiple  dimensions.  Unfortunately  however,  multiple  inheritance  poses  challenges  it¬ 
self. 

There  are  two  types  of  problems  with  multiple  inheritance:  (a)  a  class  can  inherit  multiple 
features  with  the  same  name,  and  (b)  a  class  can  have  more  than  one  path  to  a  given  ances¬ 
tor  (i.e.,  the  “diamond  problem”,  also  known  as  “fork-join”  inheritance)  [42,  45],  The  first,  the 
conflicting-features  problem,  can  be  solved  by  allowing  renaming  (e.g.,  Eiffel  [31])  or  by  lin¬ 
earizing  the  class  hierarchy  [46,  45] .  However,  there  is  still  no  satisfactory  solution  to  the  dia¬ 
mond  problem. 

The  diamond  problem  arises  when  a  class  C  inherits  an  ancestor  A  through  more  than  one 
path.  This  is  particularly  problematic  when  A  has  fields — should  C  inherit  multiple  copies  of 
the  fields  or  just  one?  Virtual  inheritance  in  C++  is  designed  as  one  solution  for  C  to  inherit 
only  one  copy  of  A’s  fields  [21].  But  with  only  one  copy  of  A’s  fields,  object  initializers  are  a 
problem:  if  C  transitively  calls  A’s  initializer,  how  can  we  ensure  that  it  is  called  only  once? 
Existing  solutions  either  restrict  the  form  of  constructor  definitions,  or  ignore  some  constructor 
calls  [38,21], 

There  is  another  consequence  of  the  diamond  problem:  it  causes  multiple  inheritance  to  in¬ 
teract  poorly  with  modular  typechecking  of  multiple  dispatch.  Multiple  dispatch  is  a  very  pow¬ 
erful  language  mechanism  that  provides  direct  support  for  extensibility  and  software  evolution 
[14,  16];  for  these  reasons,  it  has  been  adopted  by  designers  of  new  programming  languages, 
such  as  Fortress  [2],  Unfortunately  however,  modular  multimethods  are  difficult  to  combine 
with  any  form  of  multiple  inheritance — even  restricted  forms,  such  as  traits  or  Java-style  mul¬ 
tiple  interface  inheritance.  Previous  work  either  disallows  multiple  inheritance  across  module 
boundaries,  or  burdens  programmers  by  requiring  that  they  always  provide  (possibly  numer¬ 
ous)  disambiguating  methods. 

To  solve  these  problems,  we  take  a  different  approach:  while  permitting  multiple  inheri¬ 
tance,  we  disallow  inheritance  diamonds  entirely.  So  that  there  is  no  loss  of  expressiveness, 
we  divide  the  notion  of  inheritance  into  two  concepts:  an  inheritance  dependency  (expressed 
using  a  requires  clause,  an  extension  of  a  Scala  construct  [38])  and  implementation  inheri¬ 
tance  (expressed  through  extends).  Through  examples,  we  illustrate  that  programs  that  are  ex¬ 
pressed  using  diamond  inheritance  can  be  translated  to  a  hierarchy  that  uses  a  combination 
of  requires  and  extends,  without  the  presence  of  diamonds.  As  a  result,  our  language,  CZ — for 
cubic  zirconia — retains  the  expressiveness  of  diamond  inheritance. 

We  argue  that  a  hierarchy  with  multiple  inheritance  is  conceptually  two  or  more  separate  hi¬ 
erarchies.  These  hierarchies  represent  different  “dimensions”  of  the  class  that  is  multiply  inher¬ 
ited.  We  express  dependencies  between  these  dimensions  using  requires,  and  give  an  extended 
example  of  its  use  in  Sect.  5. 

Our  solution  has  two  advantages:  fields  and  multiple  inheritance  (including  initializers) 
can  gracefully  co-exist,  and  multiple  dispatch  and  multiple  inheritance  can  be  combined.  To 
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achieve  the  latter,  we  make  an  incremental  extension  to  existing  techniques  for  modular  type¬ 
checking  of  multiple  dispatch.1 

An  additional  feature  of  our  language  is  a  dynamically-dispatched  super  call,  modelled  after 
trait  super  calls  [19],  When  a  call  is  made  to  A. super./ ()  on  an  object  with  dynamic  type  D,  the 
call  proceeds  to  /  defined  within  D’s  immediate  superclass  along  the  A  path.  With  dynamically- 
dispatched  super  calls  and  requires,  our  language  attains  the  expressiveness  of  traits  while  still 
allowing  classes  to  inherit  state. 

We  have  formalized  our  system  as  an  extension  of  Featherweight  Java  (FJ)  [28]  (Sect.  8)  and 
have  proved  it  sound  (Appendix  B). 

Contributions: 

•  The  design  of  a  novel  multiple  inheritance  scheme2  that  solves  (1)  the  object  initializa¬ 
tion  problem  and  (2)  the  modular  typechecking  of  multimethods,  by  forbidding  diamond 
inheritance  (Sections  2  and  4). 

•  Generalization  of  the  requires  construct  and  integration  with  dynamically-dispatched  su¬ 
per  calls  (Sect.  6). 

•  Examples  that  illustrate  how  a  diamond  inheritance  scheme  can  be  converted  to  one 
without  diamonds  (Sections  3  and  5). 

•  Examples  from  actual  C++  and  Java  programs,  illustrating  the  utility  of  multiple  inheri¬ 
tance  and  inheritance  diamonds  (Sect.  7). 

•  A  formalization  of  the  language,  detailed  argument  of  modularity  (Sect.  8),  and  proof  of 
type  safety. 

•  An  implementation  of  a  typechecker  for  the  language,  as  an  extension  of  the  JastAddJ  Java 
compiler  [20], 


2  Object  Initialization 

To  start  with,  diamond  inheritance  raises  a  question:  should  class  C  with  a  repeated  ancestor 
A  have  two  copies  of  A’s  instance  variables  or  just  one — i.e.,  should  inheritance  be  “tree  inheri¬ 
tance”  or  “graph  inheritance”  [13]?  As  the  former  may  be  modelled  using  composition,  the  latter 
is  the  desirable  semantics;  it  is  supported  in  languages  such  as  Scala,  Eiffel,  and  C++  (the  last 
through  virtual  inheritance)  [38,  31,  21].  Unfortunately,  the  object  initialization  problem  occurs 
in  this  semantics,  depending  how  and  when  the  superclass  constructor  or  initializer  is  called 
[46,  45], 

1  For  simplicity  and  ease  of  understanding,  our  formal  system  only  allows  dispatch  on  a  method’s  receiver  and 
its  first  argument,  corresponding  to  double  dispatch.  The  system  can  be  easily  generalized  to  /(-argument  multi¬ 
methods,  as  all  interesting  typechecking  issues  also  arise  in  the  two-argument  case.  See  Sect.  8  for  further  details. 

2This  is  a  revised  and  expanded  version  of  a  paper  presented  at  the  FOOL  ’09  workshop  [30].  (FOOL  has  no 
archival  proceedings  and  is  not  intended  to  preclude  later  publication.)  The  main  changes  are  the  inclusion  of 
multimethods  rather  than  external  methods  and  a  new  section  on  real-world  examples  (Sect  7). 
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Figure  1:  An  inheritance  diamond.  Italicized  class  names  indicate  abstract  classes. 


The  Problem.  To  illustrate  the  problem,  consider  Figure  1,  which  shows  a  class  hierarchy  con¬ 
taining  a  diamond.  Suppose  that  the  Stream  superclass  has  a  constructor  taking  an  integer,  to 
set  the  size  of  a  buffer.  InputStream  and  OutputStream  call  this  constructor  with  different  val¬ 
ues  (1024  and  2048,  respectively).  But,  when  creating  an  InputOutputStream,  with  which  value 
should  the  Stream  constructor  be  called?  Moreover,  InputStream  and  OutputStream  could  even 
call  different  constructors  with  differing  parameter  types,  making  the  situation  even  more  un¬ 
certain. 

Previous  Solutions.  Languages  that  directly  attempt  to  solve  the  object  initialization  problem 
include  Eiffel  [31],  C++  [21],  Scala  [38]  and  Smalltalk  with  stateful  traits  [8], 

In  Eiffel,  even  though  (by  default)  only  one  instance  of  the  repeatedly  inherited  class  is  in¬ 
cluded  (e.g.,  Stream),  when  constructing  an  InputOutputStream,  the  Stream  constructor  is  called 
twice.  This  has  the  advantage  of  simplicity,  but  unfortunately  it  does  not  provide  the  proper  se¬ 
mantics;  Stream’s  constructor  may  perform  a  stateful  operation  (e.g.,  allocating  a  buffer),  and 
this  operation  would  occur  twice. 

In  C++,  if  virtual  inheritance  is  used  (so  that  there  is  only  one  copy  of  Stream),  the  con¬ 
structor  problem  is  solved  as  follows:  the  calls  to  the  Stream  constructor  from  InputStream 
and  OutputStream  are  ignored,  and  InputOutputStream  must  call  the  Stream  constructor  explic¬ 
itly.3  Though  the  Stream  constructor  is  called  only  once,  this  awkward  design  has  the  problem 
that  constructor  calls  are  ignored.  The  semantics  of  InputStream  may  require  that  a  particu¬ 
lar  Stream  constructor  be  called,  but  the  language  semantics  would  ignore  this  dependency  by 
bypassing  the  constructor  call. 

Scala  provides  a  different  solution:  trait  constructors  may  not  take  arguments.  (Scala  traits 
are  abstract  classes  that  may  contain  state  and  may  be  multiply  inherited.)  This  ensures  that 
InputStream  and  OutputStream  call  the  same  super-trait  constructor,  causing  no  ambiguity  for 
InputOutputStream.  Though  this  design  is  simple  and  elegant,  it  restricts  expressiveness  (in 
fact,  the  Scala  team  is  currently  seeking  a  workaround  to  this  problem  [49]). 

Smalltalk  with  stateful  traits  [8]  does  not  contain  constructors,  but  by  convention,  objects 

3Since  there  is  no  default  Stream  constructor,  this  call  cannot  be  automatically  generated. 
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are  initialized  using  an  initialize  message.  Unfortunately,  this  results  in  the  same  semantics  as 
Eiffel;  here,  the  Stream  constructor  would  be  called  twice  [7] .  The  only  way  to  avoid  this  prob¬ 
lem  would  be  to  always  define  a  special  initializer  that  does  not  call  the  superclass  initializer. 
Requiring  that  the  programmer  define  such  a  method  essentially  means  that  the  C++  solution 
must  be  hand-coded.  Aside  from  being  tedious  and  error-prone,  this  has  the  same  drawbacks 
as  the  C++  semantics. 

Mixins  and  traits  do  not  address  the  object  initialization  problem  directly,  but  instead  re¬ 
strict  the  language  so  that  the  problem  does  not  arise  in  the  first  place.  We  compare  CZ  to  each 
of  these  designs  in  Sect.  3.2. 

3  An  Overview  of  CZ 

This  section  describes  the  CZ  language  design  at  a  high  level,  including  a  description  of  how  CZ 
addresses  the  object  initialization  problem  and  a  comparison  to  related  language  designs. 

3.1  CZ  Design 

CZ’s  design  is  based  on  the  intuition  that  there  are  relationships  between  classes  that  are  not 
captured  by  inheritance,  and  that  if  class  hierarchies  could  express  richer  interconnections,  in¬ 
heritance  diamonds  need  not  exist.  Suppose  the  concrete  class  C  extends  A.  As  noted  by  Scharli 
et  al.,  it  is  beneficial  to  recognize  that  C  serves  two  roles:  (1)  it  is  a  generator  of  instances,  and  (2) 
it  is  a  unit  of  reuse  (through  subclassing)  [43] .  In  the  first  role,  inheritance  is  the  implementa¬ 
tion  strategy  and  may  not  be  omitted.  In  the  second  role,  however,  it  is  possible  to  transform  the 
class  hierarchy  to  one  where  an  inheritance  dependency  between  C  and  A  is  stated  and  where 
subclasses  of  C  inherit  from  both  C  and  A.  The  key  distinguishing  feature  of  CZ  is  this  notion 
of  inheritance  dependency,  because  while  multiple  inheritance  is  permitted,  inheritance  dia¬ 
monds  are  forbidden. 

Consider  the  inheritance  diamond  of  Fig.  1.  To  translate  this  hierarchy  to  CZ,  InputStream 
would  be  made  abstract  and  its  relationship  to  Stream  would  be  changed  from  inheritance  to  an 
inheritance  dependency,  requiring  that  (concrete)  subclasses  of  InputStream  also  inherit  from 
Stream.  In  other  words,  InputStream  requires  the  presence  of Stream  in  the  extends  clause  of  con¬ 
crete  subclasses,  but  it  need  not  extend  Stream  itself.  Since  InputStream  is  now  abstract  (making 
it  serve  only  as  a  unit  of  reuse),  it  can  be  safely  treated  as  a  subtype  of  Stream.  However,  any 
concrete  subclasses  of  InputStream  (generators  of  instances),  must  also  inherit  from  Stream. 
Accordingly,  InputOutputStream  must  inherit  from  Stream  directly. 

We  have  reified  this  notion  of  an  inheritance  dependency  using  the  requires  keyword,  a  gen¬ 
eralized  form  of  a  similar  construct  in  Scala  [39,  38], 4 

Definition  3.1  (Subclassing).  The  subclass  relation  is  defined  as  the  reflexive,  transitive  closure 
of  the  extends  relationship. 

4In  Scala,  requires  is  used  to  specify  the  type  of  a  method’s  receiver  (i.e.,  it  is  a  selftype),  and  does  not  create  a 
subtype  relationship.  As  far  as  the  Scala  team  is  aware,  our  proposed  use  of  requires  is  novel  [49]. 


4 


Figure  2:  The  stream  hierarchy  of  Fig.  1,  translated  to  CZ,  with  an  encryption  extension  in  gray. 
Italicized  class  names  indicate  abstract  classes,  solid  lines  indicate  extends,  and  dashed  lines 
indicate  requires. 

Definition  3.2  (Requires). 

When  a  class  C  requires  a  class  B,  we  have  the  following: 

•  C  is  abstract 

•  C  is  a  subtype  of  B  (but  not  a  subclass) 

•  Subclasses  of  C  must  either  require  B  themselves  (making  them  abstract)  or  extend  B  (al¬ 
lowing  them  to  be  concrete).  This  is  achieved  by  including  a  requires  B'  or  extends  B' 
clause,  where  B '  is  a  subclass  of  B. 

In  essence,  C  requires  B  is  a  contract  thatC’s  concrete  subclasses  will  extend  B. 

The  revised  stream  hierarchy  is  displayed  in  Fig.  2.  In  the  original  hierarchy,  InputStream 
served  as  both  generator  of  instances  and  a  unit  of  reuse.  In  the  revised  hierarchy,  we 
divide  the  class  in  two — one  for  each  role.  The  class  ConcretelnputStream  is  the  gener¬ 
ator  of  instances,  and  the  abstract  class  InputStream  is  the  unit  of  reuse.  Accordingly, 
InputStream  requires  Stream,  and  ConcretelnputStream  extends  both  InputStream  and  Stream. 
The  concrete  class  InputOutputStream  extends  each  of  Stream,  InputStream,  and  OutputStream, 
creating  a  sub  typing  diamond,  but  not  a  sub  classing  diamond,  as  requires  does  not  create  a 
subclass  relationship. 

The  code  for  InputStream  will  be  essentially  the  same  as  before,  except  for  the  call  to  its  super 
constructor  (explained  further  below).  Because  InputStream  is  a  subtype  of  Stream,  it  may  use 
all  the  fields  and  methods  of  Stream,  without  having  to  define  them  itself. 

Programmers  may  add  another  dimension  of  stream  behavior  through  additional  abstract 
classes,  for  instance  EncryptedStream.  EncryptedStream  is  a  type  of  stream,  but  it  need  not  ex¬ 
tend  Stream,  merely  require  it.  Concrete  subclasses,  such  as  EncryptedlnputStream  must  inherit 
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from  Stream,  which  is  achieved  by  extending  ConcretelnputStream.  (It  would  also  be  possible  to 
extend  Stream  and  InputStream  directly.) 

The  requires  relationship  can  also  be  viewed  as  declaring  a  semantic  “mixin” — if  B  requires 
A,  then  B  is  effectively  stating  that  it  is  an  extension  of  A  that  can  be  “mixed-in”  to  clients.  For 
example,  EncryptedStream  is  enhancing  Stream  by  adding  encryption.  Because  the  relationship 
is  explicitly  stated,  it  allows  B  to  be  substitutable  for  A. 

Using  requires  is  preferable  to  using  extends  because  the  two  classes  are  more  loosely  cou¬ 
pled.  For  example,  we  could  modify  EncryptedlnputStream  to  require  InputStream  (rather  than 
extend  ConcretelnputStream).  A  concrete  subclass  of  EncryptedlnputStream  could  then  also  ex¬ 
tend  a  subclass  of  InputStream,  such  as  BufferedlnputStream,  rather  than  extending  InputStream 
directly.  In  this  way,  different  pieces  of  functionality  can  be  combined  in  a  flexible  manner  while 
avoiding  the  complexity  introduced  by  inheritance  diamonds. 

Object  initialization.  Because  there  are  no  inheritance  diamonds,  the  object  initialization 
problem  is  trivially  solved.  Note  that  if  class  C  requires  A,  it  need  not  (and  should  not)  call 
A’s  constructor,  since  C  does  not  inherit  from  A.  In  our  example,  InputStream  does  not  call 
the  Stream  constructor,  while  ConcretelnputStream  calls  the  constructors  of  its  superclasses, 
InputStream  and  Stream.  Thus,  a  sub  typing  diamond  does  not  cause  problems  for  object  ini¬ 
tialization. 

This  may  seem  similar  to  the  C++  solution;  after  all,  in  both  designs,  InputOutputStream 
calls  the  Stream  constructor.  However,  the  CZ  design  is  preferable  for  two  reasons:  a)  there  are 
no  constructor  calls  to  non-direct  superclasses,  and,  more  importantly,  b)  no  constructor  calls 
are  ignored.  In  the  C++  solution,  InputStream  may  expect  a  particular  Stream  constructor  to  be 
called;  as  a  result,  it  may  not  be  properly  initialized  when  this  call  is  ignored.  Essentially,  CZ 
does  not  allow  the  programmer  to  create  constructor  dependencies  that  cannot  be  enforced. 

Using  “requires”.  Introducing  two  kinds  of  class  relationships  raises  the  question:  when 
should  programmers  use  requires,  rather  than  extends?  A  rule  of  thumb  is  that  requires  should 
be  used  when  a  class  is  an  extension  of  another  class  and  is  itself  a  unit  of  reuse.  If  necessary, 
a  concrete  class  extending  the  required  class  (such  as  ConcretelnputStream)  could  also  be  de¬ 
fined  to  allow  object  creation.  Note  that  this  concrete  class  definition  would  be  trivial,  likely 
containing  only  a  constructor.  On  the  other  hand,  when  a  class  hierarchy  contains  multiple 
disjoint  alternatives  (such  as  in  the  AST  example  in  the  next  section),  extends  should  be  used; 
the  no-diamond  property  is  also  a  semantic  property  of  the  class  hierarchy  in  question. 

The  above  guideline  may  result  in  programmers  defining  more  abstract  classes  (and  corre¬ 
sponding  concrete  classes)  than  they  may  have  otherwise  used.  However,  some  argue  that  it 
is  good  design  to  make  a  class  abstract  whenever  it  can  be  a  base  class.  This  is  in  accordance 
with  the  design  of  classes  in  Sather  [48],  traits  in  Scala  and  Fortress  [38, 2,  3],  and  the  advice  that 
“non-leaf”  classes  in  C++  be  abstract  [32],  In  Sather  and  Fortress,  for  example,  only  abstract 
classes  may  have  descendants;  concrete  classes  (called  “objects”  in  Fortress)  form  the  leaves  of 
the  inheritance  hierarchy  [48] .  Furthermore,  a  language  could  define  syntactic  sugar  to  ease  the 
task  of  creating  concrete  class  definitions;  we  sketch  such  a  design  in  Sect.  6.4. 
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3.2  Related  Work 


Subtyping  and  subclassing.  Since  requires  provides  subtyping  without  subclassing,  our  de¬ 
sign  may  seem  to  bear  similarity  to  other  work  that  has  also  separated  these  two  concepts  (e.g. 
[27, 18,  48, 15, 29]).  There  is  an  important  difference,  however,  regarding  information  hiding.  In 
a  language  that  separates  subclassing  and  subtyping,  an  “interface”  type  cannot  contain  private 
members;  otherwise  superclasses  would  be  able  to  access  private  members  defined  in  sub¬ 
classes.  Unfortunately,  this  restriction  can  be  problematic  for  defining  binary  methods  such  as 
the  equals  method;  its  argument  type  must  contain  those  private  members  for  the  method  be 
able  to  access  them.  But,  for  this  type  to  contain  private  members,  it  must  be  tied  to  a  particular 
class  implementation,  as  only  subclasses  (as  opposed  to  subtypes)  should  conform  to  this  type. 
See  Appendix  A  for  an  example  illustrating  this  issue. 

This  difficulty  does  not  arise  when  using  requires,  as  it  establishes  a  stronger  relation¬ 
ship  than  just  subtyping;  concrete  subclasses  must  (directly  or  indirectly)  inherit  from  the  re¬ 
quired  class,  as  opposed  to  any  class  that  provides  a  particular  interface.  Therefore,  Stream 
may  define  an  equals(Stream)  method,  and  objects  of  type  e.g.  InputStream,  OutputStream,  or 
InputOutputStream  may  be  safely  passed  to  this  method.  Since  the  private  member  is  defined 
in  Stream  and  is  only  accessed  by  a  method  of  Stream,  this  does  not  violate  information  hiding. 

Mixins.  Mixins,  also  known  as  abstract  subclasses,  provide  many  of  the  reuse  benefits  of  mul¬ 
tiple  inheritance  while  fitting  into  a  single  inheritance  framework  [  12,  5, 24, 22,  4,  9] .  While  mix¬ 
ins  allow  defining  state,  they  have  the  drawbacks  that  they  must  be  explicitly  linearized  by  the 
programmer  and  they  cannot  inherit  from  one  another  (though  most  systems  allow  expressing 
implementation  dependencies,  such  as  abstract  members).  If  mixin  inheritance  were  allowed, 
this  would  be  essentially  equivalent  to  Scala  traits,  which  do  have  the  object  initialization  prob¬ 
lem.  Additionally,  the  lack  of  inheritance  has  the  consequence  that  mixins  do  not  integrate  well 
with  multiple  dispatch;  multiple  dispatch  requires  an  explicit  inheritance  hierarchy  on  which 
to  perform  the  dispatch. 

Traits.  Traits  were  proposed  as  a  mechanism  for  finer-grained  reuse,  to  solve  the  reuse  prob¬ 
lems  caused  by  mixins  and  multiple  inheritance  [19,  23,  39],  In  particular,  the  linearization 
imposed  by  mixins  can  necessitate  the  definition  of  numerous  “glue”  methods  [19] .  This  design 
avoids  many  problems  caused  by  multiple  inheritance  since  fields  may  not  be  defined  in  traits. 

Unfortunately,  this  restriction  results  in  other  problems.  In  particular,  non-private  accessors 
in  a  trait  negatively  impact  information  hiding:  if  a  trait  needs  to  use  state,  this  is  encoded  using 
abstract  accessor  methods,  which  must  then  be  implemented  by  the  class  composed  using  the 
trait.  Consequently,  it  is  impossible  to  define  “state”  that  is  private  to  a  trait — by  definition, 
all  classes  reusing  the  trait  can  access  this  state.  Additionally,  introducing  new  accessors  in  a 
trait  results  in  a  ripple  effect,  as  all  client  classes  must  now  provide  implementations  for  these 
methods  [8] ,  even  if  there  are  no  other  changes. 

In  contrast,  CZ  allows  a  class  to  multiply  inherit  other  classes,  which  may  contain  state.  In 
particular,  a  class  may  extend  other  concrete  classes,  while  in  trait  systems,  only  traits  may  be 
multiply  inherited. 
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Stateful  traits.  Stateful  traits  [8]  were  designed  to  address  the  aforementioned  problems  with 
stateless  traits.  But,  as  previously  mentioned,  this  language  does  not  address  the  problem  of 
a  correct  semantics  for  object  initialization  in  the  presence  of  diamonds.  Additionally,  stateful 
traits  do  not  address  the  information  hiding  problem,  as  they  have  been  designed  for  maximal 
code  reuse.  In  this  design,  state  is  hidden  by  default,  but  clients  can  “unhide”  it,  and  may  have 
to  resort  to  merging  variables  that  are  inherited  from  multiple  traits.  While  this  provides  a  great 
deal  of  flexibility  for  trait  clients,  this  design  does  not  allow  traits  to  define  private  state. 


4  Modular  Multiple  Dispatch 

CZ  also  supports  multiple  dispatch,  which  we  and  others  believe  is  more  natural  and  more 
expressive  than  single  dispatch  [14,  16,  15].  In  fact,  one  common  source  of  bugs  in  Java  pro¬ 
grams  occurs  when  programmers  expect  static  overloading  to  behave  in  a  dynamic  manner 
[26],  Multiple  dispatch  also  avoids  the  extensibility  problem  inherent  in  the  Visitor  pattern,  as 
well  as  the  complexity  introduced  by  manual  double  dispatch.  However,  typechecking  mul¬ 
tiple  dispatch  in  a  modular  fashion  is  very  difficult  in  the  presence  of  any  form  of  multiple 
inheritance — precisely  because  of  the  diamond  problem. 

4.1  The  Problem 

To  see  why  diamond  inheritance  causes  problems,  suppose  we  have  the  original  diamond 
stream  hierarchy,  and  we  now  define  a  multimethod  seek  in  a  helper  class  (supposing  that  such 
functionality  did  not  already  exist  in  the  classes  in  question): 

class  StreamHelper  { 
void  seek(Stream  s,  long  pos)  { 

//  default  implementation:  do  nothing 

} 

void  seek(Stream@InputStream  is,  long  pos)  { 

It  seek  if  pos  <=  eofPos 

} 

void  seek(Stream@OutputStream  os,  long  pos)  { 

//  if  pos  >  eofPos,  fill  with  zeros 

} 

} 

The  declaration  seek(Stream@InputStream,  long)  specifies  that  the  method  specializes 
seek(Stream,  long)  for  the  case  that  the  first  argument  dynamically  has  type  InputStream. 

Unfortunately,  in  the  context  of  our  diamond  hierarchy,  this  method  definition  is 
ambiguous — what  if  we  perform  the  call  h.seek(new  InputOutputStream( ),  1024)?  Unfortu¬ 
nately,  it  is  difficult  to  perform  a  modular  check  to  determine  this  fact.  When  typecheck¬ 
ing  the  definition  of  seek(),  we  cannot  search  for  a  potential  subclass  of  both  InputStream 
and  OutputStream,  as  this  analysis  would  not  be  modular.  And,  when  typechecking 
InputOutputStream,  we  cannot  search  for  multimethods  defined  on  both  of  its  superclasses, 
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as  that  check  would  not  be  modular,  either.  We  provide  a  detailed  description  of  the  conditions 
for  modularity  in  Sect.  8.1. 

It  is  important  to  note  that  this  problem  is  not  confined  to  multiple  (implementation) 
inheritance — it  arises  in  any  scenario  where  an  object  can  have  multiple  dynamic  types  on 
which  dispatch  is  performed.  For  instance,  the  problem  appears  if  dispatch  is  permitted  on 
Java  interfaces,  as  in  JPred  [25] ,  or  on  traits,  as  in  Fortress  [3,2],  For  this  reason,  some  languages 
restrict  the  form  of  dispatch  to  the  single-inheritance  case;  e.g.,  Multijava  disallows  dispatching 
on  interfaces  [16, 17]. 

4.2  Previous  Solutions 

There  are  two  main  solutions  to  the  problem  of  modular  typechecking  of  multiple  dispatch 
in  the  presence  of  multiple  inheritance.  The  first  solution  is  simply  to  restrict  expressiveness 
and  disallow  multiple  inheritance  across  module  boundaries;  this  is  the  approach  taken  by  the 
“System  M”  type  system  for  Dubious  [36], 

JPred  [25]  and  Fortress  [3]  take  a  different  approach.  The  diamond  problem  arises  in  these 
languages  due  to  multiple  interface  inheritance  and  multiple  trait  inheritance,  respectively.  In 
these  languages,  the  typechecker  ensures  that  multimethods  are  unambiguous  by  requiring 
that  the  programmer  always  specify  a  method  for  the  case  that  an  object  is  a  subtype  of  two  or 
more  incomparable  interfaces  (or  traits).  In  our  streams  example,  the  programmer  would  have 
to  provide  a  method  like  the  following  in  the  StreamHelper  class  (in  JPred  syntax): 

void  seek(Stream  s,  long  pos)  when  s@InputStream  &&s@OutputStream 

(In  Fortress,  the  method  would  be  specified  using  intersection  types.)  Note  that  in  both  lan¬ 
guages,  this  method  would  have  to  be  defined  for  every  subset  of  incomparable  types  (that 
contains  at  least  2  members),  regardless  of  whether  a  type  like  InputOutputStream  will  ever  be 
defined.  Even  if  two  types  will  never  have  a  common  subtype,5  the  programmer  must  specify  a 
disambiguating  method,  one  that  perhaps  throws  an  exception.  Thus,  the  problem  with  this  ap¬ 
proach  is  that  the  programmer  is  required  to  write  numerous  additional  methods — exponential 
in  the  number  of  incomparable  types — some  of  which  may  never  be  called.  JPred  alleviates  the 
problem  somewhat  by  providing  syntax  to  specify  that  a  particular  branch  should  be  preferred 
in  the  case  of  an  ambiguity,  but  it  may  not  always  be  possible  for  programmers  to  know  in  ad¬ 
vance  which  method  to  mark  as  preferred. 

Note  that  neither  JPred  interfaces  nor  Fortress  traits  may  contain  state  and  thus  the  lan¬ 
guages  do  not  provide  a  solution  to  the  object  initialization  problem;  neither  does  Dubious, 
since  it  does  not  contain  constructors. 

These  solutions  and  the  previously  described  related  work  are  summarized  in  Table  1. 

5In  Fortress,  the  programmer  may  specify  that  two  traits  are  disjoint,  meaning  that  there  will  never  be  a  subtype 
of  both.  To  allow  modular  typechecking,  this  disjoint  specification  must  appear  on  one  of  the  two  trait  definitions, 
which  means  that  one  must  have  knowledge  of  the  other;  consequently  this  is  not  an  extensible  solution. 
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Language 

Object  initialization 

Multimethod  ambiguity 

Eiffel 

repeat  initialization 

- 

C++ 

special  constructor  semantics 

- 

Scala 

no-arg  constructors 

- 

Fortress  traits 

n/a 

disambiguating  methods 

Stateful  traits 

repeat  initialization 

- 

Mixins 

linearization 

- 

JPred 

n/a 

disambiguating  methods 

Dubious 

n/a 

MI  restrictions 

Table  1:  Summary  of  related  work  and  solutions  to  the  object  initialization  and  modular  multi¬ 
method  problems. 

4.3  Multimethods  in  CZ 

To  solve  the  problem  of  modular  multiple  dispatch,  we  use  the  same  solution  as  for  the  ob¬ 
ject  initialization  problem:  inheritance  diamonds  are  forbidden,  and  requires  is  used  as  a  sub¬ 
stitute.  An  additional  constraint  is  that  a  multimethod  may  only  specialize  a  method  in  a 
superclass,  not  a  required  class  (i.e.,  specialization  is  based  on  subclassing,  not  subtyping). 
So,  in  the  CZ  hierarchy  of  Fig.  2,  the  typechecker  will  signal  an  error,  since  the  definitions 
seek(Stream@InputStream,  long)  and  seek(Stream@OutputStream,  long)  are  not  valid  special¬ 
izations  of  seek(Stream,  long). 

Let  us  suppose  for  a  moment  that  all  classes  in  Fig.  2  have  been  defined,  except 
InputOutputStream.  Accordingly,  we  would  re-write  the  seek  methods  as  follows: 

class  StreamHelper  { 

//  helper  methods 

void  seekInput(InputStream  s,  long  pos)  { ... } 
void  seekOutput(OutputStream  s,  long  pos)  { ... } 

//  multimethods 
void  seek(Stream  s,  long  pos)  { } 
void  seek(Stream@ConcreteInputStream  is,  long  pos)  { 
seeklnput(is,  pos)  j 

} 

void  seek(Stream@ConcreteOutputStream  os,  long  pos)  { 
seekOutput(os,  pos)  j 

} 

} 

(Though  these  definitions  are  slightly  more  verbose  than  before,  syntactic  sugar  could  be  pro¬ 
vided,  particularly  for  mapping  multimethods  to  helper  methods.) 

Note  that  the  typechecker  does  not  require  that  a  method  be  provided  for 
“InputStream  &&  OutputStream,”  unlike  JPred  and  Fortress.  If  a  programmer  now  defines 
InputOutputStream,  but  does  not  provide  a  new  specialization  for  seek,  the  default  implemen- 
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tation  of  seek(Stream)  will  be  inherited.  An  specialization  for  InputOutputStream  can  then  be 
implemented,  perhaps  one  that  calls  seekOutput( ) .  Note  that  this  override  need  not  be  defined 
in  Stream  Helper  directly;  the  method  may  be  defined  in  one  of  its  subclasses. 

Here,  it  is  of  key  importance  that  subclassing  diamonds  are  disallowed;  because  they  cannot 
occur,  multimethods  can  be  easily  checked  for  ambiguities.  Sub  typing  diamonds  do  not  cause 
problems,  as  multimethod  specialization  is  based  on  sub  classing. 

Dispatch  semantics.  There  are  two  dispatch  semantics  that  can  be  used  for  multimethods: 
asymmetric  or  symmetric.  In  asymmetric  dispatching,  the  order  of  arguments  affects  dispatch. 
In  particular,  earlier  arguments  are  treated  as  more  important  when  selecting  between  equally 
specific  methods.  This  semantics  is  used  in  a  number  of  languages,  such  as  Common  Lisp  and 
parasitic  methods,  among  others  [47,  40, 1, 11,  6], 

Other  languages  employ  the  symmetric  dispatch  semantics,  where  all  arguments  have  equal 
priority  in  determining  method  lookup  [15,  44,  17,  35],  Some  argue  that  symmetric  dispatch  is 
more  intuitive  and  less  error-prone  than  asymmetric  dispatch  [17,  35],  though  this  form  of  dis¬ 
patch  adversely  affects  information  hiding.  In  particular,  a  class  may  not  hide  the  existence 
of  a  particular  method  specialization;  this  information  is  needed  to  correctly  perform  ambigu¬ 
ity  checking  of  subclasses  [35],  For  this  reason,  and  to  simplify  the  type  system  and  method 
lookup  rules,  CZ  multimethod  dispatch  is  asymmetric.  However,  CZ  is  compatible  with  sym¬ 
metric  dispatch;  a  symmetric-dispatch  version  of  CZ  would  simply  require  additional  (modu¬ 
lar)  checks  on  multimethod  definitions.  Incidentally,  method  lookup  need  not  change,  as  these 
new  ambiguity  checks  would  ensure  the  same  result,  regardless  of  whether  asymmetric  lookup 
or  symmetric  lookup  were  used.  Section  8  describes  these  issues  in  more  detail. 

Fragments  of  CZ.  Note  that  it  would  be  possible  to  omit  multimethods  from  the  language  and 
use  the  CZ  design  (as  is)  for  only  the  object  initialization  problem.  That  is,  our  solution  can  be 
used  to  solve  either  the  object  initialization  problem,  the  modular  multimethod  problem,  or 
both. 

5  Example:  Abstract  Syntax  Trees 

Consider  a  simple  class  hierarchy  for  manipulating  abstract  syntax  trees  (ASTs),  such  as  the 
one  in  Fig.  3.  The  original  hierarchy  is  the  one  on  the  left,  which  consists  of  ASTNode,  Num, 
Var,  and  Plus.  An  ASTNode  contains  a  reference  pointing  to  its  parent  node,  as  indicated  in  the 
figure.  Each  of  the  concrete  subclasses  of  ASTNode  implements  its  own  version  of  the  abstract 
ASTNode. eval( )  method. 

Suppose  we  wish  to  add  debugging  support  to  our  AST,  after  the  original  hierarchy  is  de¬ 
fined.  Each  node  now  additionally  has  a  source  location  field,  Debug  Node,  location.  Debugging 
support,  on  the  right  side  of  the  figure,  is  essentially  a  new  dimension  of  AST  nodes  that  has 
a  dependency  on  ASTNode.  We  express  this  using  requires.  Now,  classes  like  DebugPlus  can 
multiply  inherit  from  ASTNode  and  Debug  Node  without  creating  a  subclassing  diamond.  In 
particular,  DebugPlus  does  not  inherit  two  copies  of  the  parent  field,  because  Debug  Node  is  a 
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Figure  3:  The  AST  node  example  in  CZ.  Abstract  classes  and  abstract  methods  are  set  in  italic. 

class  DebugNode  requires  ASTNode  { 

ASTNode  eval( )  { 

print(this.toString( ) ) ; 

return  ASTNode. super. eval( )  j  //  dynamic  super  call 

} 

} 

class  DebugPlus  extends  DebugNode,  Plus  { 

ASTNode  eval( )  { 

return  DebugNode. super. eval( )  j  // ordinary  super  call 

} 


Figure  4:  Implementing  a  mixin-like  debug  class  using  dynamically-dispatched  super  calls,  and 
performing  multimethod  dispatch  on  the  ASTNode  hierarchy. 


subtype,  but  not  a  subclass,  of  ASTNode.  Thus,  the  no-diamond  property  allows  fields  and  mul¬ 
tiple  inheritance  to  co-exist  gracefully. 

In  this  example,  each  of  these  classes  has  a  method  eval()  which  evaluates  that  node  of 
the  AST,  as  in  the  code  in  Fig.  4.  Suppose  we  intend  DebugNode  to  act  as  a  generic  wrapper 
class  for  each  of  the  subclasses  of  ASTNode.  This  can  be  implemented  by  using  a  dynamically- 
dispatched  super  call  of  the  form  ASTNode. super.eval( )  after  performing  the  debug-specific 
functionality  (in  this  case,  printing  the  node’s  string  representation).  The  prefix  ASTNode. super 
means  “find  the  parent  class  of  the  dynamic  class  of  this  along  the  ASTNode  path.”  At  run¬ 
time,  when  eval  ( )  is  called  on  an  instance  of  DebugPlus,  the  chain  of  calls  proceeds  as  follows: 
DebugPlus.evalQ  — >■  DebugNode.evalQ  — >■  Plus.evalQ.  If  the  dynamically-dispatched  super  call 
behaved  as  an  ordinary  super  call,  it  would  fail,  because  DebugNode  has  no  superclass. 

Each  of  the  DebugNode  subclasses  implements  its  own  eval()  method  that  calls 
DebugNode. eval  ( )  with  an  ordinary  super  call.  (This  could  be  omitted  if  the  language  linearized 
method  overriding  based  on  the  order  of  inheritance  declarations,  such  as  in  Scala  traits.)  Dy¬ 
namic  super  calls  are  a  generalization  of  ordinary  super  calls,  when  the  qualifier  class  is  a  re- 
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quired  class. 


Adding  multimethods.  Suppose  that  after  we  have  defined  these  classes,  we  wish  to  add  a 
new  method  that  operates  over  the  AST.  For  instance,  we  may  want  to  check  that  variables  are 
declared  before  they  are  used  (assuming  a  variable  declaration  statement).  Since  CZ  has  mul¬ 
timethods,  such  a  method  defCheckQ  could  be  defined  in  a  helper  class,  rather  than  in  the 
classes  of  the  original  hierarchy: 

class  DefChecker  { 

void  defCheck(ASTNode  n)  { ... } 
void  defCheck(ASTNode@Var  v)  { ... } 
void  defCheck(ASTNode@Plus  p)  { ... } 
void  defCheck(ASTNode@Num  n)  { ... } 

} 

Note  that  the  programmer  would  only  have  to  define  cases  for  ASTNode,  Num,  Var  and  Plus; 
she  need  not  specify  what  method  should  be  called  when  an  object  has  a  combination  of  these 
types — such  a  situation  cannot  occur  (as  there  are  no  diamonds). 

Discussion.  The  examples  illustrate  that  subtyping  allows  substitutability;  subclassing,  in  ad¬ 
dition  to  providing  inheritance,  defines  semantic  alternatives  that  may  not  overlap  (such  as 
Num,  Var  and  Plus  in  the  example  above).  Because  they  do  not  overlap,  we  can  safely  perform 
an  unambiguous  “case”  analysis  on  them — that  is,  multimethod  dispatch.  In  other  words,  dis¬ 
patch  in  our  system  is  analogous  to  case-analyzing  datatypes  in  functional  programming  (e.g. 
ML,  Haskell). 

Alternative  designs.  Traits  could  be  used  to  express  this  example,  but  as  previously  mentioned 
(Sect.  3.2),  the  lack  of  state  results  in  an  information  hiding  problem  with  accessors.  Also,  as  we 
have  noted,  stateful  traits  do  not  address  the  object  initialization  problem. 

Mixins  could  express  some  aspects  of  the  class  hierarchy  for  this  example,  but  as  previously 
mentioned,  subclassing — or  even  subtyping — cannot  be  specified  among  (standard-style)  mix- 
ins  [12,  24,  4],  For  this  reason,  mixins  do  not  integrate  well  with  multimethods.  For  details  on 
this  issue,  see  [30], 

Using  Java-style  single  inheritance  would  be  unwieldy.  A  forwarding  pattern  would  have  to 
be  used,  along  with  the  definition  of  at  least  four  new  interfaces  [30] .  Additionally,  accessors 
would  have  to  be  public,  since  they  would  have  to  be  defined  in  an  interface  (the  only  way 
to  achieve  any  form  of  multiple  inheritance  in  Java-like  languages).  Finally,  the  Visitor  design 
pattern  would  have  to  be  used  in  order  to  allow  new  operations  to  be  defined. 

6  CZ  Design 

In  this  section,  we  give  informal  details  of  the  typechecking  rules  in  CZ,  and  provide  an  intuition 
as  to  why  typechecking  is  modular.  In  Sect.  8  we  formalize  CZ  and  provide  a  detailed  argument 
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showing  its  modularity. 


6.1  Multiple  Inheritance 

CZ  places  the  following  constraints  on  class  definitions: 

Cl.  If  a  class  C  extends  D\  and  D2  then  there  must  not  exist  some  E,  other  than  Object,  such 
that  both  D\  and  D2  are  subclasses  of  E  (the  no-diamond  property). 

C2.  If  class  C  extends  D\  and  D2  and  the  unspecialized  method  m  is  defined  or  inherited  by 
both  D\  and  D2  then  C  must  also  define  the  unspecialized  method  m.  Also,  if  method 
m  with  specializer  B  is  defined  or  inherited  by  both  D\  and  D2,  then  C  must  also  define 
either  (1)  m  with  specializer  B' ,  where  B  is  a  subclass  of  B’ ,  or  (2)  an  unspecialized  method 
m. 

Additionally,  the  calculus  assumes  an  elaboration  phase  that  translates  method  names  to  qual¬ 
ified  names,  using  the  name  of  the  class  where  the  method  was  first  defined;  consequently, 
methods  have  a  unique  point  of  introduction.  That  is,  in  the  calculus,  two  classes  only  share 
a  method  name  if  it  exists  in  a  common  superclass  or  common  required  class.  This  conven¬ 
tion  prevents  a  name  clash  if  two  methods  in  unrelated  classes  A  and  B  coincidentally  have  the 
same  name  and  a  third  class  inherits  from  both  A  and  B. 6  (Of  course,  an  implementation  of  the 
language  would  have  to  provide  a  syntactic  way  for  disambiguating  methods  that  accidentally 
have  the  same  name;  this  could  be  achieved  through  rename  directives,  e.g.,  Eiffel  [31],  or  by 
using  qualified  names,  e.g.,  C#  interfaces  and  C++.) 

We  have  already  described  the  reason  for  condition  Cl,  the  no-diamond  property.  We  make 
a  special  case  for  the  class  Object — the  root  of  the  inheritance  hierarchy,  since  every  class  au¬ 
tomatically  extends  it.  (Otherwise,  a  class  could  never  extend  two  unrelated  classes — the  exis¬ 
tence  of  Object  would  create  a  diamond.7)  Note  that  this  does  not  result  in  the  object  initial¬ 
ization  problem,  because  Object  has  only  a  no-argument  constructor.  Also,  this  condition  does 
not  preclude  a  class  from  inheriting  from  two  concrete  classes  if  this  does  not  form  a  diamond. 

Condition  C2  ensures  that  if  a  class  C  inherits  two  identical  method  definitions,  either  spe¬ 
cialized  or  unspecialized,  this  will  not  lead  to  an  ambiguity;  in  such  a  case,  C  must  provide  an 
overriding  definition. 

6.2  Multiple  Dispatch 

CZ  allows  methods  to  be  specialized  on  a  subclass  of  the  first  argument’s  class  type.  Any  unspe¬ 
cialized  method  (i.e.,  an  ordinary  method)  defined  or  inherited  by  a  class  C  may  be  specialized 
within  C,  provided  the  method’s  first  argument  type  is  not  Object.  In  general,  typechecking 
multimethods  has  two  components:  exhaustiveness  checking  (i.e.,  the  provided  cases  provide 

incidentally,  this  is  not  the  convention  used  in  Java  interfaces,  but  is  that  of  C#. 

7An  alternative  design  would  be  to  make  every  abstract  class  implicitly  require  Object  and  every  concrete  class 
implicitly  extend  Object.  The  problem  with  this  design  is  that  it  would  prevent  a  class  from  extending  two  concrete 
classes,  as  a  diamond  with  Object  at  the  root  would  result. 
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full  coverage  of  the  dispatch  hierarchy)  and  ambiguity  checking  (i.e.,  when  executing  a  given 
method  call,  there  is  a  unique  most  specific  applicable  method). 

Since  the  core  calculus  of  CZ  does  not  include  abstract  methods,  exhaustiveness  is  automat¬ 
ically  handled;  we  need  only  ensure  there  are  no  ambiguities.  (Abstract  methods  are  orthogonal 
to  our  considerations,  as  they  are  adequately  handled  by  previous  work  [36,  16,  34].)  We  adapt 
previous  techniques  for  ambiguity  checking  [36, 16,  34]: 

Ml.  A  method  D  m{A@B  x,  D  x)  may  only  be  defined  if  in  class  C  if  all  of  the  following  hold: 

1.  A  ^Object 

2.  BAA 

3.  B  is  a  subclass  of  A 

4.  a  method  D  m{A,  D )  is  defined  or  inherited  by  C. 

These  conditions,  together  with  with  Cl  and  C2,  ensure  the  absence  of  ambiguity.  In  particular, 
since  B  must  be  a  strict  subclass  of  A,  condition  Cl  ensures  that  if  method  m[A@B')  is  defined 
or  inherited  by  C,  then  either  B  <  B'  or  B'  <  B  (since  A  A  Object  and  inheritance  diamonds 
are  disallowed).  Condition  C2  ensures  that  if  B  =  B' ,  there  exists  a  disambiguating  definition 
m{A@B")  within  class  C,  where  B  <  B".  Together,  these  properties  ensure  that  if  a  program 
typechecks,  a  unique  most-specific  applicable  method  always  exists. 

Previous  work  either  disallowed  inheritance  across  module  boundaries  [36]  or  did  not  per¬ 
mit  interfaces  to  be  specializers  [16] .  In  CZ,  we  can  remove  each  of  these  restrictions,  due  to  the 
absence  of  inheritance  diamonds. 

In  Sect.  8,  we  describe  a  generalization  of  multimethods  to  the  n-argument  case  and  de¬ 
scribe  why  this  generalization  does  not  introduce  new  typechecking  issues. 

6.3  Dynamically-Dispatched  Super  Calls 

As  illustrated  in  Sect.  5,  CZ  includes  dynamically-dispatched  super  calls.  When  A  requires  B 
(i.e.,  A  is  acting  as  a  mixin  extension  of  B),  then  within  A,  a  call  of  the  form  B. super  is  dynami¬ 
cally  resolved,  similar  to  super  calls  in  traits.  Other  super  calls  (i.e.,  those  where  the  qualifier  is 
a  parent  class)  have  the  same  semantics  as  that  of  Java. 

6.4  Discussion 

Extensions.  External  methods  (also  known  as  open  classes),  could  also  be  added  to  CZ,  with¬ 
out  sacrificing  modular  typechecking.  External  methods  are  more  general  than  multimethods, 
since  they  allow  new  classes  to  override  an  existing  external  method.  For  details  on  the  type- 
checking  issues  that  arise,  see  our  previous  work  [30], 

It  would  also  be  possible  to  combine  our  solution  with  existing  techniques  for  dealing  with 
the  object  initialization  and  modular  multiple  dispatch  problems.  A  programmer  could  specify 
that  a  class  C,  whose  constructor  takes  no  arguments,  may  be  the  root  of  a  diamond  hierar¬ 
chy.  Then,  we  would  use  the  Scala  solution  for  ensuring  that  C’s  constructor  is  called  only  once. 
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To  solve  the  multiple  dispatch  problem,  if  methods  m{B )  and  m[B')  specialize  m(C),  the  type- 
checker  would  ensure  that  m  contained  a  disambiguating  definition  for  ( B  A  B ') — the  JPred  and 
Fortress  solutions. 

Finally,  the  language  could  include  syntactic  sugar  to  ease  the  definition  of  concrete  classes. 
If  C  requires  B,  and  both  C  and  B  have  no-argument  constructors,  the  compiler  could  automat¬ 
ically  generate  a  class  C$concrete  that  extends  both  C  and  5;  programmers  could  then  more 
easily  define  multimethods  that  dispatch  on  C$concrete. 

Encapsulation  and  the  diamond  problem.  As  noted  by  Snyder,  there  are  two  possible  ways 
to  view  inheritance:  as  an  internal  design  decision  chosen  for  convenience,  or  as  a  public  dec¬ 
laration  that  a  subclass  is  specializing  its  superclass,  thereby  adhering  to  its  semantics  [46], 
Though  Snyder  believes  that  it  can  be  useful  to  use  inheritance  without  it  being  part  of  the 
external  interface  of  a  class,  we  argue  that  the  second  definition  of  inheritance  is  more  appro¬ 
priate.  In  fact,  if  inheritance  is  being  used  merely  out  of  convenience  (e.g.,  Stack  extending 
Vector  in  the  Java  standard  library),  then  it  is  very  likely  that  composition  is  a  more  appropriate 
design  [10].  For  similar  reasons,  we  do  not  believe  a  language  should  allow  inheritance  without 
subtyping — e.g.,  C++  private  inheritance — as  this  can  always  be  implemented  using  a  helper 
class  whose  visibility  is  restricted  using  the  language’s  module  system. 

Nevertheless,  if  one  takes  the  view  that  inheritance  choices  should  not  be  visible  to  sub¬ 
classes,  a  form  of  the  diamond  problem  can  arise  in  CZ.  In  particular,  suppose  class  D  extends 
B  and  C,  C  extends  A,  and  B  extends  Object — a  valid  hierarchy  (recall  that  condition  Cl  makes 
a  special  exception  for  diamonds  involving  Object).  Now  suppose  that  B  is  changed  to  extend 
A,  and  the  maintainer  of  B  is  unaware  that  class  D  exists.  Now  A,  B  and  C  typecheck,  but  D 
does  not.  Thus,  the  use  of  inheritance  can  invalidate  subclasses,  which  violates  Snyder’s  view 
of  encapsulation. 

This  situation  highlights  the  fact  that,  in  general,  requires  should  be  favored  over  extends  if 
a  class  is  intended  to  be  reused. 

7  Real-World  Examples 

In  this  section,  we  present  real-world  examples  (in  both  C++  and  Java)  that  suggest  that  multi¬ 
ple  inheritance,  and  diamond  inheritance  in  particular,  can  be  useful  for  code  reuse.  We  also 
describe  how  these  examples  can  be  expressed  in  CZ. 

7.1  C++ Examples 

We  examined  several  open-source  C++  applications  in  a  variety  of  domains  and  found  many 
instances  of  virtual  inheritance  and  inheritance  diamonds.  Here  we  describe  inheritance  dia¬ 
monds  in  two  applications:  Audacity8  and  Guikachu.9 

8  http://audacity.sourceforge.net/ 

9  http://cactus.rulez.org/projects/guikachu/ 
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Audacity.  Audacity  is  a  cross-platform  application  for  recording  and  editing  sounds.  One  of 
its  main  storage  abstractions  is  the  class  BlockedSequence  (not  shown),  which  represents  an 
array  of  audio  samples,  supporting  operations  such  as  cut  and  paste.  A  BlockedSequence  is 
composed  of  smaller  chunks;  these  are  objects  of  type  Seq Block,  depicted  in  Fig.  5  (a).  One 
subclass  of  SeqBlock  is  SeqDataFileBlock,  which  stores  the  block  data  on  disk.  One  superclass  of 
SeqDataFileBlock  is  ManagedFile,  an  abstraction  for  temporary  files  that  are  de-allocated  based 
on  a  reference-counting  scheme.  Since  both  ManagedFile  and  SeqBlock  inherit  from  Storable  (to 
support  serialization),  this  forms  a  diamond  with  Storable  at  the  top. 


(a)  (b) 


Figure  5:  An  inheritance  diamond  (a)  in  the  Audacity  application,  and  (b)  the  re-written  class 
hierarchy  in  CZ.  Abstract  classes  are  set  in  italic. 

This  particular  diamond  can  be  easily  re-written  in  CZ  (Fig.  5  (b)),  since  the  sides  of  the 
diamond  (SeqBlock  and  ManagedFile)  are  already  abstract  classes.  (Compare  to  the  example  in 
Fig.  2,  where  new  concrete  classes  had  to  be  defined  for  the  sides  of  the  diamond.)  Flere,  we  sim¬ 
ply  change  the  top  two  virtual  inheritance  edges  to  requires  edges,  and  make  SeqDataFileBlock 
inherit  from  Storable  directly.  This  may  even  be  a  preferable  abstraction;  while  in  the  original 
hierarchy  SeqDataFileBlock  is  serializable  by  virtue  of  the  fact  that  SeqBlock  is  serializable,  in  the 
new  hierarchy  we  are  making  this  relationship  explicit. 

Guikachu.  Guikachu  is  a  graphical  resource  editor  for  the  GNU  PalmOS  SDK.  It  allows  pro¬ 
grammers  to  graphically  manipulate  GUI  elements  for  a  Palm  application  in  the  GNOME 
desktop  environment.  In  this  application,  we  found  10  examples  of  diamonds  that  included 
the  classes  Canvasltem,  WidgetCanvasItem,  and  ResizeableCanvasItem.  Canvasltem  is  an  ab¬ 
stract  base  class  that  represents  items  that  can  be  placed  onto  a  canvas,  while  objects  of  type 
WidgetCanvasItem  and  ResizeableCanvasItem  are  a  type  of  widget  or  are  resizeable,  respectively. 

Figure  6(a)  shows  two  of  these  10  diamonds,  formed  by  TextFieldCanvasItem  and 
PopupTriggerCanvasItem,  respectively.  The  hierarchy  was  likely  designed  this  way  because  there 
exist  GUI  elements  that  have  only  one  of  the  two  properties.  For  instance,  GraffitiCanvasItem 
and  LabelCanvasItem  (not  shown)  are  not  resizeable,  but  they  are  widgets.  In  contrast,  the  class 
FormCanvasItem  (not  shown)  is  resizeable,  but  is  not  a  widget. 

In  this  application,  we  also  observed  the  use  of  the  C++  virtual  inheritance  initializer  invoca¬ 
tion  mechanism:  TextFieldCanvasItem  (for  instance)  directly  calls  the  initializer  of  Canvasltem, 
its  grandparent.  As  previously  described,  when  initializing  TextFieldCanvasItem,  the  initializer 
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Figure  6:  Two  inheritance  diamonds  in  the  Guikachu  application  (a)  and  re-written  in  CZ  (b). 
Abstract  classes  are  set  in  italic. 

calls  from  WidgetCanvasItem  and  ResizeableCanvasItem  to  Canvasltem  are  ignored.  In  this  ap¬ 
plication,  the  initializers  happen  to  all  perform  the  same  operation,  but  this  invocation  seman¬ 
tics  could  introduce  subtle  bugs  as  the  application  evolves. 

The  corresponding  CZ  class  hierarchy  is  displayed  in  Fig.  6  (b);  note  its  similarity  to  that  of 
Fig.  5  (b).  Essentially,  the  virtual  inheritance  is  replaced  with  requires  and  each  of  the  classes  at 
the  bottom  of  the  diamond  inherit  from  all  three  of  WidgetCanvasItem,  ResizeableCanvasItem, 
and  Canvasltem.  The  CZ  design  has  the  advantage  that  constructor  calls  do  not  occur  more 
than  one  level  up  the  hierarchy,  and  no  constructor  calls  are  ignored. 

This  example  illustrates  how  a  program  could  be  translated  from  C-H--style  multiple  inheri¬ 
tance  to  CZ-style.  In  particular,  virtual  inheritance  would  be  replaced  by  requires,  and  new  con¬ 
crete  classes  would  be  defined  as  necessary  (changing  instantiations  of  the  now-abstract  class 
to  instantiations  of  the  new  concrete  class).  Note  that  constructor  calls  can  be  easily  generated 
for  the  new  concrete  classes,  as  C++  requires  a  call  from  the  bottom  of  the  diamond  to  the  top 
of  the  diamond  when  virtual  inheritance  is  used  (such  a  constructor  call  would  be  necessary  for 
the  new  concrete  class,  as  it  would  directly  extend  the  class  at  the  top  of  the  diamond). 

Discussion.  It  would  be  interesting  to  extend  the  C++  study  and  perform  a  more  systematic 
study  of  the  nature  of  inheritance  diamonds,  quantifying  how  often  new  abstract  classes  would 
have  to  be  defined  (i.e.,  how  often  concrete  classes  appear  on  the  “sides”  of  the  diamond).  One 
could  also  determine  how  often  the  initializer  problem  occurs  in  real  code. 

However,  note  that  the  multimethod  problem  will  always  arise  in  a  multiple  inheritance 
situation,  even  if  a  programmer  never  actually  creates  an  inheritance  diamond,  and  (as  noted  in 
Section  4)  even  if  a  language  includes  the  more  benign  feature  of  multiple  interface  inheritance 
(e.g.,  Java-like  languages). 

7.2  Java  Example:  Eclipse  JDT 

The  Eclipse  JDT  (Java  Development  Tools)  is  an  example  of  where  multiple  inheritance  could 
be  useful  for  Java  programs.  In  the  JDT,  every  AST  node  contains  structural  properties.  A  node’s 
structural  properties  allow  uniform  access  to  its  components.  For  example,  DoStatement  has  2 
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fields  of  type  Structural  PropertyDescriptor:  EXPRESSION_PROPERTY  and  BODY_PROPERTY.  To  get 
the  expression  property  of  a  DoStatement  object,  the  programmer  may  call  ds.getExpression( ) 
or  ds.getStructuralProperty(  DoStatement. EXPRESSION_  PROPERTY).  Structural  property  de¬ 
scriptors  are  often  used  to  specify  how  AST  nodes  change  when  a  refactoring  is  performed. 

Through  inspection  of  the  JDT  code,  we  found  that  there  was  a  great  deal  of  dupli¬ 
cation  among  the  code  for  getting  or  setting  a  node  property  using  the  structural  prop¬ 
erty  descriptors.  For  example,  19  AST  classes  (e.g.,  AssertStatement  and  ForStatement)  have 
getExpression/setExpression  properties.  As  a  result,  in  the  method  intemalGetSetChildProperty 
(an  abstract  method  of  ASTNode),  there  are  19  duplications  of  the  following  code: 

if  (property  ==  EXPRESSION_PROPERTY)  { 
if  (get)  { 

return  getExpression  ( )  j 
}  else  { 

setExpression  ( ( Expression )  child )  j 

return  null; 

} 

}  else  if  (property  ==  BODY_PROPERTY)  { 

...II  code  for  body  property 

} 

} 

Additionally,  there  are  duplicate,  identical  definitions  of  the  EXPRESSION_PROPERTY  field.  With¬ 
out  a  form  of  multiple  inheritance,  however,  it  is  difficult  to  refactor  this  code  into  a  com¬ 
mon  location — DoStatement,  for  example,  already  has  the  superclass  Statement.  With  mul¬ 
tiple  inheritance,  the  programmer  could  create  an  abstract  helper  class  ExprPropertyHelper 
that  requires  ASTNode.  This  new  class  would  contain  the  field  definition  and  an  override 
of  intemalGetSetChildProperty.  DoStatement  would  then  inherit  from  both  Statement  and 
ExprPropertyHelper  and  would  have  the  following  body  for  intemalGetSetChildProperty: 

if  (property  ==  BODY_PROPERTY)  { 

...II  code  for  body  property 

}  else{ 

return  ExprPropertyHelper. super. 

internalGetSetChildProperty(property,  get,  child)  j 

} 

Additionally,  this  is  a  scenario  where  multiple  dispatch  would  be  beneficial.  The  framework 
defines  various  visitors  for  traversing  an  AST;  these  could  be  omitted  in  favor  of  multimethods, 
which  are  more  extensible. 

Overall,  our  real-world  examples  suggest  that  multiple  inheritance  can  be  useful,  and  that 
even  diamond  inheritance  is  used  in  practice.  We  have  shown  that  the  inheritance  diamonds 
can  be  easily  translated  to  CZ  and  that  the  resulting  designs  offer  some  benefits  over  the  original 
ones.  In  particular,  CZ  avoids  the  problem  of  ignored  constructor  calls  in  C++,  while  providing 
more  flexible  code  reuse  than  with  single  inheritance. 
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Declarations  L  ::=  class  C  extends  C  requires  C  {C  /;  K  M] 
Constructors  K  ::=  C(C  /)  { this./  =  /;} 

Methods  M  ::=  Co  ra(Cr)  { return  e;}  |  Co  m(C@C'x,Cx)  { return  e;} 
Expressions  e  ::=  x  |  e./ 1  e.m(e)  \  e.C. super. m(e)  |newC(?) 

Figure  7:  CZ  grammar 


Subclassing 


C<D 


C<D  D<E 
C<C  C  <E 


Subtyping 


C  <:  D 


CT[C)  =  class  C extends  D\,...,Dn  ■■  ■  { ... } 
C<Dj 


C<D  C  <:  D  D<:E  CT{C)  =  class  C  extends  D  requires  E\t...,En  {...} 

C  <:  D  C  <:  E  C  <:  Ei 


Figure  8:  Subclassing  (<)  and  sub  typing  (<:)  judgement 


8  Formal  System 

In  this  section,  we  describe  the  formalization  of  CZ,  which  is  based  on  Featherweight  Java  (FJ) 
[28] .  We  use  the  same  conventions  as  FJ;  D  is  shorthand  for  the  (possibly  empty)  list  D\, . . . ,  Dn, 
which  may  be  indexed  by  Dj. 

The  grammar  of  CZ  is  presented  in  Fig.  7.  Modifications  to  FJ  are  highlighted.  Class  declara¬ 
tions  may  extend  or  require  a  list  of  classes.  There  is  also  a  new  syntactic  form  for  multimethods; 
such  methods  include  a  specializer  on  the  first  argument  type. 

We  relax  the  FJ  convention  that  a  class  may  not  define  two  methods  with  the  same  name; 
such  a  case  is  permitted  as  long  as  one  method  or  both  methods  have  specializers  (which  must 
be  distinct).  The  type  of  all  other  arguments  and  the  return  type  must  remain  the  same. 

To  simplify  the  formal  system,  we  assume  that  all  methods  have  at  least  one  argument.  A 
dummy  object  can  be  used  to  simulate  a  no-argument  method. 

To  avoid  syntax  for  resolving  different  superclass  constructors,  all  fields,  including  those 
inherited  from  superclasses,  must  be  initialized  in  the  constructor. 

Aside  from  dynamically-dispatched  super  calls,  and  the  removal  of  casts  (they  are  orthog¬ 
onal  to  our  goals),  CZ  expression  forms  are  identical  to  those  of  FJ.  For  simplicity,  we  have 
not  modeled  ordinary  super  calls  in  our  calculus,  as  this  has  been  considered  by  others  (e.g., 
[24,  37])  and  is  orthogonal  to  the  issues  we  are  considering.  Therefore,  the  class  qualifier  of  a 
super  call  must  be  a  required  class. 

We  have  added  a  new  subclass  ('<’)  judgement  (Fig.  8),  which  is  the  reflexive,  transitive 
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r  he:C 


(T-Var) 


(T-Field) 

rhe0:Co  Cq<:D  fields[D)  =  C  f 


F  I-  x :  T  (jc) 


r  h  e0.fi :  Q 


(T-Invk) 

Fheo:Co  mtype(m,Co)  =  D  —  C 


fh  e:C  C  <:  D 


(T-  Super- Invk) 

F  h  eo  :  Co  class  Co  extends  Do  requires  B,  E 
mtype[m,B)  =  D  — ►  C  TI-e:C  C  <:  D 


F  I-  e0.m[e) :  C 


T  I-  eo-B.super.m(e) :  C 


(T-New) 

fields[C)  =  D  f  TI-e:C  C<\D  class  C requires  • 


F  h  new  C(e) :  C 


Figure  9:  Expression  typing 


closure  of  extends.  The  subtype  judgement  (<:)  is  extended  to  include  the  requires  relationship. 
Subclassing  implies  subtyping,  and  if  class  A  requires  B  then  A  <:  B,  but  A  ^  B.  In  CZ,  the 
requires  relation  is  not  transitive;  subclasses  must  either  require  or  extend  the  required  class, 
which  is  enforced  by  the  typechecking  rules.  Subtyping  allows  A  be  used  in  place  of  B,  which  is 
in  contrast  to  Scala;  Scala  only  allows  such  a  substitution  for  the  this  reference  within  a  class. 

The  auxiliary  judgements  for  typechecking  appear  after  the  typechecking  and  evaluation 
rules,  in  Fig.  12.  We  will  describe  each  of  these  when  describing  the  rules  that  use  them. 

Static  Semantics.  The  rules  for  typechecking  expressions  are  in  Fig.  9.  The  rule  for  method 
invocations,  T-Invk,  is  the  same  as  that  in  FJ.  However,  the  auxiliary  judgement  it  uses,  mtype, 
is  different. 

The  CZ  judgement  mtype  (Fig.  12)  has  an  additional  rule  as  compared  to  FJ;  it  performs  a 
lookup  of  methods  from  required  classes,  in  the  case  that  the  method  does  not  exist  in  the  class 
itself  or  superclasses.  This  judgement  considers  only  unspecialized  methods. 

The  rule  T-  Super- Invk  checks  the  dynamically-dispatched  super  call  described  in  Sect.  6. 
Essentially,  for  a  call  of  the  form  this.S.super.ra(e),  where  this  :  C0,  instead  of  looking  up 
mtype{m,  Co),  we  look  up  mtype{m,  B ),  where  B  is  a  required  class  of  Co. 

The  rule  T-New  has  one  additional  premise  as  compared  to  FJ:  the  requires  clause  must  be 
empty.  This  ensures  that  the  class  is  concrete  and  can  be  instantiated,  which  in  turn  ensures 
the  soundness  of  the  subtyping  relation  induced  by  requires. 

Rules  for  typechecking  methods  are  displayed  in  Fig.  10.  The  rule  T-Method  checks  unspe¬ 
cialized  methods,  and  uses  the  override  auxiliary  judgement  (which  is  unchanged  from  FJ).  In 
this  rule,  we  check  that  method  m  is  a  valid  override  of  the  same  (unspecialized)  method  in  all 
superclasses  and  required  classes. 

T-Multi-Method  checks  specialized  methods.  The  first  two  premises  are  the  same  as  that  of 
T-Method.  Premises  (3),  (4)  and  (5)  check  conditions  1,  2,  and  3,  respectively,  of  constraint  Ml. 
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(T- Multi -Method) 


Figure  10:  Specialized  and  unspecialized  method  typing 
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®  Vi-fields(Dj)  =  Ft  g,:  0  E  =  C(  Ft  gi  iEh  n  ,  C  /){ this.g,-  =  gf  iel  '"  ;  this./  =  /} 
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0  Vi.  V;  #  z'.2E>'  /  Object. Dj  <  D'  and  Dj  <  D' 
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and B0  m{{A@)B" x,Bx)  eM 

class  C  extends  D  requires!?  {C  f;K  M]  ok 


(T- Class) 


Figure  11:  Class  typing 


Premise  (6)  checks  condition  4  of  Ml;  it  ensures  C  defines  or  inherits  an  unspecialized  method 
with  type  [A,  B)  -*  B,  where  A  is  the  static  type  being  specialized. 

The  T-Class  rule  (Fig.  11)  checks  class  definitions.  Premises  (1-3)  are  straightforward  gener¬ 
alizations  of  the  corresponding  premises  in  FJ.  Premises  (4)  and  (5)  ensure  that  requires  is  prop¬ 
agated  down  each  level  of  the  inheritance  hierarchy;  the  extending  class  must  either  extend 
or  require  its  parents’  required  classes.  Premise  (6)  specifies  that  a  subclassing  diamond  can¬ 
not  occur,  except  for  the  case  of  Object  (condition  Cl).  Finally,  premise  (7)  enforces  condition 
C2,  ensuring  that  if  C  inherits  two  methods  m  with  the  same  first  argument  B'  (or  two  unspe¬ 
cialized  methods  m),  then  C  provides  an  overriding  definition  for  m.  This  premise  uses  the 
methodDefim,  Di,B')  auxiliary  judgement:  a  derivation  of  methodDef  exists  if  Dj  defines  or 
inherits  a  method  with  specializer  B'  or  first  argument  type  B' .  This  premise,  as  well  as  the 
methodDef  judgement,  uses  the  notation  (A@)  to  specify  either  a  specialized  or  unspecialized 
method  (i.e.,  the  A@  part  is  optional). 

Dynamic  Semantics.  The  evaluation  rules  and  auxiliary  judgements  are  presented  in  Fig.  13. 
Most  of  the  rules  are  similar  to  FJ,  with  the  exception  of  E-Invk  and  E-Super-Invk.  E-Invk  passes 
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Figure  12:  CZ  typechecking  auxiliary  judgements 


the  dynamic  type  of  the  method’s  first  argument  as  an  additional  argument  to  mbody,  which 
we  describe  below.  E-  Super- Invk  uses  the  auxiliary  judgement  superiC,  D),  which  finds  the  first 
superclass  of  the  class  C  that  is  also  a  subclass  of  D.  Then,  mbody  is  called  on  the  result  of  the 
super  call. 

The  main  changes  to  the  dynamic  semantics  are  encoded  in  the  auxiliary  judgements 
mbody,  dispatch,  and  match.  The  mbody  judgement  has  one  additional  argument  as  com¬ 
pared  with  FJ,  to  (potentially)  dispatch  on  the  method’s  first  argument.  This  judgement  sim¬ 
ply  extracts  the  arguments  and  method  body  from  the  result  of  the  dispatch  judgement,  which 
contains  the  actual  dispatch  logic. 

Method  dispatch  is  performed  in  two  steps.  The  first  dispatch  rule  uses  the  matchArg  judge¬ 
ment  to  search  for  a  method  defined  in  C  that  is  applicable  for  D,  the  dynamic  type  of  the 
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method’s  first  argument.  This  latter  judgement  considers  both  specialized  and  unspecialized 
methods  (via  the  ( B@ )  notation).  If  such  a  definition  exists,  it  is  returned;  otherwise,  a  set  of 
methods  Me  is  composed  by  calling  dispatch  on  each  of  C’s  superclasses.  Then,  the  unique 
most  specific  method  that  is  applicable  for  argument  D  is  selected.  Note  the  asymmetric  dis¬ 
patch  semantics;  if  an  appropriate  method  does  not  exist  in  C,  its  superclasses  are  searched 
before  dispatching  on  the  argument  type. 

Constructors.  As  in  FJ,  CZ  does  not  contain  state,  and  thus  constructor  definitions  are  triv¬ 
ial.  However,  a  full  implementation  would  have  to  ensure  that  when  C  extends  A,  B  and 
A  requires  B,  when  creating  a  C  object,  its  5-part  must  be  initialized  before  its  A-part.  Oth¬ 
erwise,  this  could  result  in  fields  being  accessed  before  they  exist,  since  A  is  permitted  to  access 
B’s  fields. 

Generalizations.  To  generalize  multimethod  dispatch  to  n  arguments,  in  the  static  semantics, 
we  would  extend  premise  (7)  of  T-Class,  which  corresponds  to  condition  C2.  In  particular,  this 
premise  would  ensure  that  if  C  inherits  two  method  definitions  that  have  identical  specializer 
lists  (or  argument  types),  then  an  overriding  definition  exists  in  C.  In  particular,  the  quantifier 
MB'  would  become  MB  in  this  premise. 

For  the  dynamic  semantics,  we  would  change  dispatch  and  matchArg  to  take  a  list  of  dy¬ 
namic  types  of  the  objects  passed  to  the  method  in  question.  The  latter  judgement  would  then 
select  the  unique  most  specific  method  such  that  each  of  its  specializers  (or  argument  types, 
if  there  is  no  specializer)  is  a  supertype  of  the  corresponding  dynamic  type.  This  could  be  im¬ 
plemented  by  first  creating  a  candidate  list  of  all  applicable  methods,  then  selecting  the  most 
specific  one. 

We  observe  from  the  form  of  these  judgements  ( dispatch  and  matchArg )  that  there  could  be 
two  ways  in  which  more  than  one  method  applies:  (1)  within  a  single  argument  position,  more 
than  one  method  applies  and  none  is  more  specific  than  the  others,  (2)  one  method  is  more 
specific  at  one  argument  position  and  another  method  is  more  specific  at  some  other  argument 
position.  Note  that,  in  the  absence  of  appropriate  typechecking,  either  situation  can  arise,  re¬ 
gardless  of  whether  dispatch  is  performed  on  n  arguments  or  just  two  arguments.  Premise  (6) 
of  T-Multi-Method  ensures  that  there  exists  at  least  one  method  in  the  candidate  list. 

CZ’s  static  semantics — in  particular,  conditions  Cl  and  C2 — ensure  that  the  first  situation 
cannot  arise.  As  a  consequence  of  condition  Cl  (the  no-diamond  restriction),  for  a  particular 
argument  position  k,  all  specializer  types  in  the  candidate  method  list  are  mutually  comparable 
(via  subclassing).  That  is,  if,  at  argument  position  k,  method  m,-  has  specializer  Q  and  mj  has 
specializer  Cj,  then  either  C,  <  Cj  or  Cj  <  Ci  (for  i  ^  j).  This  is  because  both  types  must  be 
superclasses  of  D/c  (the  dynamic  type  at  position  k)  and  they  also  must  both  be  subtypes  of  Q-, 
the  static  type  at  position  k.  Since  Q-  cannot  be  Object,  Q  and  Cj  must  be  comparable  types. 

C2  ensures  that  there  exists  an  argument  position  k  such  that  Cj  ^  Cj.  We  observe  that  two 
methods  in  the  candidate  list  could  only  have  identical  specializer  types  (or  argument  types)  if 
class  C  inherited  two  such  methods  (as  there  is  a  syntactic  restriction  against  such  a  definition 
directly  in  C).  But,  C2  ensures  that  if  such  a  situation  were  to  occur,  that  C  would  have  an 
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Figure  13:  Evaluation  rules  and  auxiliary  judgements 
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overriding  definition.  Therefore,  the  first  dispatch  rule  would  apply  and  superclasses  would  not 
be  considered. 

Finally,  situation  (2)  cannot  occur,  due  our  assymmetric  dispatch  semantics.  To  change  to 
symmetric  dispatch  (described  in  Sect.  4.3),  we  need  only  add  an  additional  premise  to  T- Class. 
This  new  premise  would  ensure  that  there  is  no  combination  of  receiver  and  argument  tuples 
such  that  more  than  one  method  would  apply,  using  the  same  modular  check  implemented  in, 
for  instance,  Multijava  and  EML  [17,  34],  Note  that  the  dynamic  semantics  would  not  need  to 
change,  since  this  new  premise  would  ensure  that  asymmetric  and  symmetric  dispatch  produce 
the  same  result. 

8.1  Modularity 

Here,  we  describe  the  conditions  under  which  a  class-based  system  is  modular  when  there  is 
no  explicit  module  system.  We  argue  informally  that  typechecking  in  CZ  is  modular  based  on 
the  structure  of  the  typechecking  rules.  (The  other  languages  we  have  mentioned  also  perform 
modular  typechecking  by  this  definition.) 

Conditions  for  modular  typechecking. 

1.  Checking  a  class  signature  C  with  methods  M  should  only  require  examining:  (a)  signa¬ 
tures  of  methods  transitively  overridden  or  specialized  in  M,  (b)  signatures  of  methods 
transitively  overridden  or  specialized  by  C’s  inherited  methods,  (c)  class  declarations  of 
C’s  supertypes. 

2.  Checking  the  definition  of  a  particular  method  m  (possibly  specialized  with  class  C) 
should  only  require  examining:  (a)  the  declarations  of  C  and  its  supertypes,  (b)  the  signa¬ 
ture  of  the  method  that  m  specializes,  and  (c)  the  signatures  of  methods  called  by  m. 

By  inspection,  checking  a  class  definition  C  obeys  condition  1.  Each  premise  examines  only 
superclasses  or  required  classes,  and  there  is,  for  example,  no  search  for  multimethods  with 
first  argument  type  C. 

Checking  a  method  definition  m  is  also  modular.  If  m  is  an  unspecialized  method,  the  only 
generalization  to  the  typechecking  rule  is  additional  override  checks,  which  are  modular.  On  the 
other  hand,  when  a  specialized  method  is  checked,  we  simply  ensure  that  the  specializer  has 
the  appropriate  relationship  to  its  static  type  (which  may  not  be  Object),  and  call  mtype{m,  C). 
Since  this  judgement  only  searches  up  the  subtype  hierarchy,  it  is  modular. 

8.2  Type  Safety 

We  prove  type  safety  using  the  standard  progress  and  preservation  theorems,  with  a  slightly 
stronger  progress  theorem  than  that  of  FJ,  due  to  the  omission  of  casts.  Note  that  in  our  system, 
type  safety  implies  that  all  method  calls  are  unambiguous,  as  the  dispatch  and  match  judge¬ 
ments  require  that  there  be  a  unique  most-applicable  method.  We  describe  below  a  brief  out¬ 
line  of  the  proof  of  type  safety  and  refer  the  reader  to  Appendix  B  for  further  details. 

Theorem  8.1  (Preservation).  If  T  h  e:  C  and  e  > — *  e\  then  T  \-  e'  :C'  for  some  C'  <:  C. 
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The  proof  of  preservation  is  relatively  straightforward  and  is  similar  to  the  proof  of  FJ.  We  make 
use  of  an  auxiliary  lemma  (not  shown)  that  proves  that  mtype  returns  a  unique  value.  The  proof 
of  this  lemma  makes  use  of  the  convention  that  method  introductions  are  unique. 

Theorem  8.2  (Progress).  If  •  h  e:  C  then  either  e  is  a  value  or  there  is  an  e'  with  e  > — *  e'. 

The  proof  of  progress  is  slightly  more  complex.  The  proof  requires  the  following  lemma: 

Lemma  8.1.  If  mtype[m,C)  =  (B0,B)  —>  B  and  T  I-  new  C(e)  :  C  and  B '  <  B0  then 
dispatchim,  C,  B')  =  M,  for  some  M. 

However,  unlike  in  FJ,  we  cannot  prove  this  lemma  by  induction  on  the  derivation  of  mtype, 
since  for  the  inductive  step,  we  do  not  have  a  derivation  T  F  new  D ^ (?) :  D]c.  Instead,  we  make 
use  of  two  auxiliary  lemmas: 

Lemma  8.2.  If  T>  ::  mtype(m,  C)  =  (Bq,B)  — *  B  and  T>  does  not  contain  the  rule  MType3  and 
B'  <B0,  then  dispatchim,  C,  B ')  =  M,  for  some  M. 

Lemma  8.3.  If  T  F  new  C(F) :  C  and  C  <:  D  and  T> ::  mtype{m,D )  =  B  —>  B,  then  there  exist  D' 
and  T>'  such  that  C  <D'  and  D' ::  mtype{m,  D ')  =  B  — ►  B  does  not  contain  the  rule  MType3. 

Lemma  8.2  is  needed  because  it  is  the  rule  MType3  that  could  result  in  mbody  not  being 
defined — it  is  the  only  rule  that  has  no  dispatch  counterpart.  We  use  Lemma  8.3  to  produce 
such  an  mtype  derivation. 

With  these  lemmas,  the  rest  of  the  proof  of  progress  is  straightforward. 


9  Related  Work 

Here  we  describe  related  work  that  was  not  previously  discussed  in  Sections  2,  3.2,  and  4.2. 

As  mentioned  in  Sect.  4.2,  JPred  [25]  and  Fortress  [3]  perform  modular  multimethod  type¬ 
checking  by  requiring  that  programmers  provide  disambiguating  methods,  some  of  which  may 
never  be  called.  However,  we  observe  that  the  JPred  and  Fortress  dispatch  semantics  may 
be  more  expressive  than  that  of  CZ.  In  CZ,  in  the  class  hierarchy  Fig.  2,  the  abstract  class 
InputStream  may  not  be  used  as  a  specializer  for  Stream,  because  it  is  not  a  subclass  of  Stream. 
In  contrast,  if  this  hierarchy  were  expressed  in  e.g.  Fortress  a  multimethod  defined  on  Stream 
could  be  specialized  for  either  InputStream  or  OutputStream.  Note,  however,  that  programmers 
can  achieve  a  similar  effect  in  CZ  by  having  concrete  classes  call  helper  methods  (which  may 
themselves  perform  multiple  dispatch)  defined  on  the  abstract  classes. 

Cecil  [14, 15]  also  provides  both  multiple  inheritance  and  multimethod  dispatch,  but  it  does 
not  include  constructors  (and  therefore  provides  ordinary  dispatch  semantics  for  methods  act¬ 
ing  as  constructors),  and  it  performs  whole-program  typechecking. 

Like  JPred,  the  language  Half  &  Half  [6]  provides  multimethod  dispatch  on  Java  interfaces. 
In  this  language,  if  there  exist  specialized  method  implementations  for  two  incomparable  inter¬ 
faces  A  and  B,  the  visibility  of  one  of  the  two  interfaces  must  be  package-private.  Like  System 
M,  this  effectively  disallows  multiple  (interface)  inheritance  across  module  boundaries  (where 
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a  package  is  a  module).  Half  &  Half  does  not  consider  the  problem  of  multiple  inheritance  with 
state. 

Pirkelbauer  et  al  have  considered  the  problem  of  integrating  multimethods  into  C++,  which 
is  especially  difficult  due  to  existing  rules  for  overload  resolution  [41].  However,  this  proposal  is 
not  modular;  because  of  the  potential  for  inheritance  diamonds,  the  design  requires  link-time 
typechecking. 

It  is  worth  noting  that  multimethods  cannot  be  simulated  with  C#  3.0  “extension  methods” 
or  partial  classes  [33] .  The  former,  extension  methods,  are  merely  syntactic  sugar  and  cannot 
be  overridden  with  a  more  specific  type  for  the  receiver.  Partial  classes,  on  the  other  hand,  are 
simple  a  compile-time  mechanism  for  splitting  a  class’s  definition  across  multiple  compilation 
units.  In  particular,  compared  to  multimethods,  they  have  the  following  limitations:  1)  they 
cannot  span  assemblies  (so  if  the  AST  node  classes  are  in  a  library,  some  other  mechanism 
would  be  needed,  such  as  the  Visitor  pattern);  2)  partial  classes  may  not  be  used  to  perform 
dispatch  on  interfaces,  in  contrast  to  multimethods;  and  3)  typechecking  each  part  of  a  partial 
class  is  not  modular,  as  all  parts  are  composed  before  typechecking.  This  last  problem  can  cause 
compilation  errors  if  two  programmers  implement  a  partial  class  in  incompatible  ways,  so  it  is 
unclear  what  should  be  the  appropriate  level  of  granularity  when  partial  classes  are  used  in  a 
team  environment. 

10  Conclusions 

We  have  presented  a  language  that  solves  two  major  problems  caused  by  inheritance  diamonds: 
object  initialization  and  modular  typechecking  of  multiple  dispatch.  We  have  also  shown  how 
programs  written  with  traditional  multiple  inheritance  can  be  converted  to  programs  in  our 
language.  We  note  that  though  diamonds  can  still  cause  encapsulation  problems  (depending 
on  the  definition  of  encapsulation),  this  problem  can  be  ameliorated  by  preferring  requires  over 
extends. 

We  emphasize  that  although  programmers  may  indeed  have  to  decide  ahead  of  time 
whether  they  want  to  make  a  class  re-usable  by  making  it  abstract  and  by  using  requires  in¬ 
stead  of  extends — potentially  a  difficult  decision  to  make — it  is  a  decision  the  class  designer 
must  already  make,  as  a  class  must  be  designed  carefully  if  it  is  to  be  a  unit  of  reuse  (e.g.,  see 
item  17  in  [32]). 

One  might  also  raise  the  objection  that  CZ  would  result  in  a  proliferation  of  abstract  classes, 
for  which  a  corresponding  concrete  class  would  have  to  be  defined.  We  believe  that  this  prob¬ 
lem  can  mostly  be  solved  through  a  syntactic  sugar  for  defining  concrete  classes  (Section  6.4). 
Additionally,  note  that  our  proposed  solution  requires  just  as  many  abstract  classes  as  there 
would  be  mixins  or  traits  (which  also  cannot  be  instantiated)  if  those  solutions  were  to  be  used 
(Section  3.2). 
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A  Subtyping  vs.  Subclassing 

In  CZ,  the  use  of  requires  provides  sub  typing  without  inheritance,  but  it  also  places  constraints 
on  concrete  subclasses — they  must  inherit  from  their  parent’s  required  classes.  This  raises  the 
question  of  whether  simply  providing  subtyping  without  inheritance  would  be  sufficient  to  en¬ 
code  the  desired  relationships. 

When  separating  subtyping  from  inheritance,  we  may  use  nominal  subtyping  or  structural 
subtyping.  However,  in  either  case,  private  members  are  problematic.  If  private  members  are 
included  in  a  subtyping  relationship,  this  can  violate  information  hiding,  if  they  are  not,  it  can 
restrict  expressiveness. 


32 


Concretely,  consider  the  following  program: 

class  A  { 

private  int  ij 

boolean  equals(A  other)  { 

...II can  access  other. i ? 

} 

} 

class  B  subtypes  A  { 

...  II declare i? 

} 

Suppose  that  the  subtypes  keyword  provides  nominal  subtyping  without  inheritance  (but  with¬ 
out  the  additional  constraints  of  requires).  The  question  then  arises:  are  private  members  con¬ 
sidered  when  checking  subtyping?  If  so,  then  B  must  declare  a  private  field  i.  Unfortunately,  this 
also  means  that  A. equals  can  access  B.i,  which  violates  information  hiding;  one  class  should  not 
be  able  to  access  private  members  defined  in  another  class.  On  the  other  hand,  if  we  assume 
that  subtyping  does  not  include  private  members,  then  A. equals  cannot  access  other. i,  which  is 
problematic  if  the  definition  of  equality  depends  on  this  field.  An  analogous  problem  occurs  if 
structural  subtyping  is  used. 

The  problem  can  be  avoided  if  inheritance  or  requires  is  used  for  types  that  contain  binary 
methods.  Since  requires  is  tied  to  a  particular  class,  if  we  change  the  above  code  to  B  requires  A 
(or  B  extends  A),  then  A.equals(A  other)  may  safely  access  other.i,  even  if  an  object  of  type  B  is 
passed  to  this  method.  Note  that  an  information  hiding  problem  does  not  arise  here — the  pri¬ 
vate  state  has  not  been  redefined  in  B,  but  is  rather  (eventually)  inherited  from  A  in  the  concrete 
B  implementation  that  was  passed  in. 


B  Type  Safety  Proof 

B.I  Auxiliary  Lemmas 

Lemma  B.I.  If  mtype[m,D)  -  C  — *  C0,  then  for  C<D,  mtype{m,C)  -C  —■  C0. 

Proof.  By  induction  on  C  <  D. 
case  Sub-CRefl.  Immediate. 

case  Sub-CTrans.  We  have  C  <  D  and  D  <E.  By  the  induction  hypothesis,  mtypelm,  D)  =  C  — ► 
Co.  Applying  the  induction  hypothesis  to  C<D  gives  the  required  result. 

case  Sub-Extends.  There  are  two  cases: 

C  defines  m.  By  inversion  on  override  and  T- Method,  m  must  be  a  valid  override  and 
must  have  type  C  -*■  Co.  By  rule  MTypeI,  mtype{m,  C)  -  C  -*■  Co. 

C  does  not  define  m.  By  rule  MType2,  mtype{m,C)  =  mtype{m,D). 
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□ 

Lemma  B.2.  If  C  <:  E  and  mtype{m,  E)  =  B  — *•  B,  then  mtype{m,  C)  =  B  — ►  B. 

Proof.  By  case  analysis  of  C<:D. 

case  Sub-Subclass.  Follows  from  Lemma  B.l. 

case  Sub-Trans.  C  <:  D  and  D  <:  E. 

By  the  induction  hypothesis  on  D  <:  E,  mtype{m,D)  =  B  — ►  B.  The  result  then  follows 
from  the  induction  hypothesis  on  C  <:  D. 

case  Sub -Requires.  There  are  two  cases: 

C  defines  m.  Similar  to  the  same  case  in  Lemma  B.l 
C  does  not  define  m.  By  rule  MType3,  mtype{m,C )  =  mtype[m,E). 


□ 

Lemma  B.3.  If  mtype{m,  C)  =  B  B  and  mtype{m,  C')  =  B  — * ►  B' ,  then  there  exists  a  D  where 
C  <:  D  and  C'  <:D  and  mtypeim,  D )  =  b"  — <•  B"  where  B  =  b'  =  b'  and  B  =  B'  =  B” . 

Proof.  By  simultaneous  induction  on  the  two  mtype  derivations. 


case  MType  1,  MType  1.  By  the  convention  that  methods  have  a  unique  point  of  introduction, 
B"  m{B  x)  must  have  been  introduced  in  some  D  where  C  <:  D  and  C'  <:  D.  By  MTypeI, 
mtype[m,  D)  =  B  — »  B" .  The  result  then  follows  from  Lemma  B.2. 

case  — ,  MType2;  — ,  MType3.  The  result  follows  from  the  induction  hypothesis  and  the  transi¬ 
tivity  of  subtyping. 


□ 

Lemma  B.4.  If  A  <  B  and  B  requires  C,  then  either  there  exists  some  C'  <  C  such  that 
A  requires  C'  or  A  <  C' . 

Proof.  Straightforward  induction  on  A<  B.  □ 

Lemma  B.5.  If  A  <:  B  and  A^B  then  there  exists  some  B'  <  B  such  that  A  requires  B' . 

Proof.  By  induction  on  A<:  B. 

case  Sub -Subclass.  Vacuous. 

case  Sub-Trans.  We  have  A<C  and  C  <B. 

Since  A^B,  there  are  three  possibilities: 
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subcase  A  ^  C,  C  -j±  B.  By  the  induction  hypothesis  on  the  first  derivation,  we  have 
3C'  <  C.A  requires  C' .  By  the  induction  hypothesis  on  the  second  derivation,  3B1  < 
B.C  requires  B' .  We  have  C'  <  C  and  C  requires  B' .  Taking  these  facts  together,  by 
Lemma  B.4,  3 B"  <  B' .  C'  requires  B"  or  C'  <  B" .  In  the  first  case,  again  by  Lemma  B.4, 
3 B'"  <  B' .  A  requires  B'" .  But,  since  B'"  <  B,  this  proves  the  required  result. 

subcase  A<  C,C  ^  B.  By  the  induction  hypothesis,  3 B1  <  B.C  requires  B' .  Since  A<C, 
by  Lemma  B.4,  3 B"  <  B' .  A  requires  B"  or  A  <  B" . 

In  the  first  case,  A  requires  B",  the  result  follows  from  the  fact  that  B"  <  B.  In  the 
second  case,  A  <  B" ,  we  have  A<  B,  which  is  a  contradiction. 

subcase  A  ^  C,  C  <  B,  by  the  induction  hypothesis,  3  C'  <  C.A  requires  C' .  The  result 
follows  from  the  fact  that  C'  <  B. 

case  Sub -Requires.  Immediate. 


□ 

Lemma  B.6.  If  matchArg(m,  A,  M)  =  M0  and  argfMf)  =  A'  then  M0  =  B0  m{(B@)A'  x,Bx)  and 

M0  g  M  and  A  <  A'. 

Proof.  By  induction  on  matchArg. 

case  Match  1.  Immediate. 

case  Match2.  We  have  matchArgi m,  A k,  M)  =  Mo,  where  A  extends  A^.  By  the  induction  hy¬ 
pothesis,  M0  e  M  and  A^  <  A' .  The  result  then  follows  from  the  transitivity  of  subclassing. 

□ 

Lemma  B.7.  If  argj (M0)  =  A'  and  M0  e  M  and  A  <  A',  then  matchArg[m,  A,  M)  =  M'  where 

arg,  (M' )  <  A'. 

Proof.  By  induction  on  A  <  A'. 

case  Sub-Refl.  Immediate  from  Match  1. 

case  Sub-CTrans.  We  have  A  <  B  and  B  <  A1.  By  the  induction  hypothesis  on  the  second 
derivation,  matchArgfn,  B ,  M)  =  M'(]  where  argBMf  <  A! .  By  Lemma  B.6,  M'0  e  M.  By 
the  induction  hypothesis  on  the  first  derivation  {A  <  B),  match Arg(m,  A,  M)  =  M"  and 
arg i  {M”)  <  argiiM'f.  By  transitivity  of  subtyping,  argj(M'')  <  A,  which  is  the  required 
result. 

case  Sub-Extends.  We  have  A  extends  A'.  Either  (1)  there  exists  M'  where  argfM')  =  A'  and 
M'eMor  (2)  M'  £  M.  In  case  (1),  by  MatchI,  matchArgfn,  A,  M)  =  A.  Otherwise,  in  case 
(2),  the  result  follows  from  Match2. 


□ 
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B.2  Progress  Lemmas  and  Proof 

_ _  def 

Definition  B.l.  argi{B  m((A@)B0  x,Bx)  { return  e;})  -  B0 

Lemma  B.8  (No-diamond  property).  If  A  <  D\  and  A<  D2  and  D\<B  and  D2  <  B,  then  either 

B  =  Object  or  D\  <  D2  or  D2<D\. 

Proof.  By  simultaneous  induction  on  A  <  Dj  and  A  <  Dj 

case  Sub-CRefl,  Sub-CRefl.  D\  =  D2.  Immediate. 

case  Sub-CRefl,  Sub-CTrans;  Sub-CRefl,  Sub-Extends.  A  =  D\.  By  assumption,  A  <  D2,  which 
is  the  required  result. 

case  Sub-CTrans,  Sub-CTrans.  We  have  A  <  Ci  and  Ci  <  D\  and  A  <  C2  and  C2  <  D2.  By 
the  transitivity  of  subclassing,  C\  <  B  and  C2  <  B.  Applying  the  induction  hypothesis  to 
A  <  Ci  and  A  <  C2,  we  have  either  (1)  B  =  Object  or  (2)  Ci  <  C2  or  (3)  C2  <  C\.  In  case  (1), 
the  result  follows.  In  case  (2),  we  have  C\<Di  and  C\<D2.  The  result  follows  by  applying 
the  induction  hypothesis  to  these  derivations.  Case  (3)  is  similar  to  case  (2). 

case  Sub-CTrans,  Sub-Extends.  We  have  A<  C  and  C  <  D\  and  A  extends  D2.  Applying  the 
induction  hypothesis  to  A  <  C  and  A  <  D2,  either  (1)  B  =  Object  or  (2)  C  <D2  or  (3)  D2  <  C. 
In  case  (2),  applying  the  induction  hypothesis  to  C  <  D\  and  C  <  D2  yields  the  required 
result.  In  case  (3),  the  result  follows  from  transitivity  of  subclassing. 

case  Sub-Extends,  Sub-Extends.  Immediate  from  T-Class. 


□ 

Lemma  B.9.  If  matchArgim,  D,  M)  =  M,  then  D  <D'  where  argi  (M)  =  D' . 

Proof.  By  induction  on  matchArg. 

case  Match  1.  D  =  D'. 

case  Match2.  We  have  matchArgim,  T/0  M)  =  M,  where  D  extends  Ejc.  By  the  induction  hy¬ 
pothesis,  argi{M)  =  D'  and  <  E'k.  By  SubCTrans,  D  <  D',  which  is  the  required  result. 


□ 


Lemma  B.  10.  If  dispatch{m,C,D)  -  M,  then  D  <  D' ,  where  argfM)  =  D' . 

Proof.  Follows  by  induction  on  dispatch  and  Lemma  B.9.  □ 

Lemma  B.ll.  If  matciiArgim,  D,  M)  =  M, t,  for  some  unique  M/c  and  Mi.argfM')  argAMf, 
then  matchArg{m,  D,  (M,  M'))  has  the  unique  result  Mk. 

Proof.  By  induction  on  match. 
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case  Match  1.  Immediate  from  the  fact  that  argfM')  f  argj{Mk). 

case  Match2.  We  have  D  extends  Ek  and  matchArgim,  Ek,  M)  =  Mk.  By  the  induction  hypoth¬ 
esis,  there  is  a  unique  Mk  where  matchArgim,  Ek,  (M,  M'))  =  Mk. 

Suppose  M'  =  B0  m{D  x,B  x ).  Then,  by  MatchI,  matchArgim,  D,iM,M'))  =  D.  But,  by 
Lemma  B.9,  Ek  <  argi(Mk)  and  therefore  D  <  argi(Mk).  By  premise,  argi(M')  argi(Mk) 
so  D  f  argi(Mk),  which  is  a  contradiction. 

Therefore,  B0  m{D  x,Bx)£  (M,M')  and  the  rule  Match2  applies,  providing  the  required 
result. 


□ 

Lemma  B.12  (Weakening  for  matchArg).  If  matchArgim,  D,  M)  =  Mk,  for  some  unique  Mk  and 
Mi  £  .  V j  e  \..#M.arg1iM'i)  ^  argfMj),  then  matchArgim, D,  (M,M))  has  the  unique  re¬ 

sult  Mk. 

Proof.  By  induction  on  M . 
case  m'  =  •.  Immediate. 

case  a/  =  M0,  m"  .  Result  follows  from  Lemma  B.ll. 


□ 

Lemma  B.13.  If  matchArgim,  A,  M)  =  M0  and  A'  <  A,  then  matchArgim,  A' ,  M)  =  Mr0  where 
arg,  (M' )  <  argjiMo). 

Proof.  By  induction  on  matchArgim,  A,  M ) . 
case  MatchI.  Follows  from  Lemma  B.7. 

case  Match2.  We  have  A  extends  Ak  and  matchArgim,  Ak,  M )  =  M0.  By  transitivity  of  subtyp¬ 
ing,  A1  <  Ak.  The  result  then  follows  from  the  induction  hypothesis. 


□ 

Lemma  B.14  (Sufficient  conditions  for  match  to  be  defined.).  If  we  have  M  where  Mi  = 
Bj  miAi  x,Bj  x)  { return  eg]  and 

1.  D  <  A(  (for  some  () 

2.  Aj  f  Aj  (for  all  i  f-  j ) 

3 .  D  <  Ai  and  D  <  Aj,  implies  Ai  <  Aj  or  Aj  <  Ai  (for  all  i  f  j ) 

then  there  exists  a  unique  Mk  such  that  matchArgim,  D,  M)  =  Mk  and  for  all  j  such  that  D<  Aj, 
Ak  <  Aj. 

Proof.  By  induction  on  M. 
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case  M  -  M0,  where  argj  (Mq)  =  D'  and  D  <  D' .  The  result  follows  from  Lemma  B.7. 
case  M  =  M0,  M ,  where  argx  (M0)  =  D' . 

Either  3k  e  l..#M  .D  <  A k  (where  argAMk)  =  Ak),  or  not.  If  such  a  A k  does  not  exist  (i.e., 
Mi.D  ^  Af,  by  assumption  D  <  D' .  By  Lemma  B.6,  matchArg{m,  D,  M0)  =  M0.  From  this 
it  follows  that  V i.  D'  ^  Ai,  and  the  result  follows  from  Lemma  B.12. 

Otherwise,  either  D  <  D'  or  not.  If  D  ^  D' ,  the  result  follows  from  Lemma  B.12. 

Therefore,  we  have  D  <  D'  and  by  assumption,  for  all  i  e  l..#M ,  D'  ^  Ai  and  if  D  ^  Ai, 
either  D'  <  Ai  or  Ai  <  D' ,  where  Aj  =  argiiM^). 

By  the  induction  hypothesis,  there  exists  a  unique  M'  such  that  matchArg{m,  D,  M )  =  M'k 
and  V  j.D  ■<  Aj  implies  A ^  <  Aj.  Since  by  Lemma  B.9,  D  <  A fc,  from  above,  either  (1) 
D'  <  Ak  or  (2)  Ak  <  D'. 

In  either  case  (1)  or  (2),  by  the  induction  hypothesis,  matchArg{m,D,{M0,M'k ))  =  M" , 
where  argAM ")  <  D'  and  argi(M")  <  Ak.  By  Lemma  B.6),  M"  e  {M0,  M'k\. 

In  case  (1),  we  can  conclude  that  M"  =  M0.  From  above,  we  have  V  j.D  <  Aj,  D'  <  Aj.  The 
result  then  follows  from  Lemma  B.12. 

In  case  (2),  we  can  conclude  that  M"  =  M'k.  The  result  then  follows  from  Lemma  B.12. 


□ 

Lemma  B.15.  If  class  C---{  C  fm,K  M}  and  M\  e  M  where  argAM\)  =  Ai  and  M2  e  M  where 
argAM\)  =  A2  and  Ai  <  A2  and  A<A\,A2  and  matchArg{m,  A,  M)  =  M' ,  then  argAM')  <  A\. 

Proof.  By  case  analysis  on  matchArg{m,  A,  M). 
case  Match  1.  Immediate. 

case  Match2.  We  have  A  extends  Ak  and  malchArgim,  Ak,  M)  =  M'  and  argAM')  =  A'k.  By 
Lemma  B.6,  matchArg(m,  A\,M)  =  M\.  Since  the  result  of  matchArg{m,  Ak,  M)  is  unique, 
Ak  <  A\.  Then,  by  Lemma  B.13,  A'  <  A\. 


□ 

Lemma  B.16.  If  class  C---{C  f-,K  M}  and  matchArg{m,  A,  M)  =  M\  and  matchArgim,  A,  M)  = 
M2  then  Mi  =  M2. 

Proof.  By  Lemma  B.6,  M\  =  B  m((Br@)B0  x,Bx)eM  and  M2  =  B'  m((B"@)B'0  x,B  x)  e  M.  By 
Lemma  B.9,  A<B0  and  A  <  B'0.  There  are  3  cases  to  consider:  (1)  3B'  and  3B" ,  (2)  (3 B'  and  3 B") 
or  (3 B'  and  3 B"),  or  (3)  3 B'  and  3 B" . 

In  case  (1),  by  T-Multi-Method,  B0  <  B'  and  B'0  <  B" .  Also  by  T-Multi-Method, 
mtype{m,C )  =  [B',B)  -*  B  and  mtype{m,C )  =  ( B",B ')  -»  B'.  By  the  uniqueness  of  mtype 


38 


(Lemma  B.3),  B'  =  B" .  By  T-Multi-Method,  B'  ^  Object.  But,  since  we  have  A<  B0  and  A  <  B '0, 
B0  =  B'0]  otherwise  this  would  violate  the  no-diamond  property  (Lemma  B.8). 

In  case  (2),  suppose  3 B'  and  3 B"  (the  other  case  is  analogous).  By  T-Multi-Method,  B0  <  B' 
and  B0  f  B'  and  mtypeim, C )  =  iB0,B)  — ►  B.  By  MTypeI,  mtypeim, C )  =  (. B'q,b')  —  B' .  By  the 
uniqueness  of  mtype  (Lemma  B.3),  B'Q  =  B' .  We  have  A<  B' ,  A<  Bo  and  Bq  <  B' .  By  Lemma  B.15, 
B'  <  Bo,  which  implies  Bo  =  B' .  This  is  a  contradiction. 

In  case  (3),  since  there  cannot  be  two  unspecialized  methods  with  the  same  name  defined 
in  C,  Mi  =  M2. 

□ 

Lemma  B.17.  If  class  C---{C  f;K  M }  and  B  m[A  x,B  x)  e  M  and  A'  <  A,  then 
matchArgim,  A',  M )  =  M0  where  arg1  (M0)  =  A"  and  A"  <  A. 

Proof.  By  induction  on  A'  <  A. 

case  Sub-CRefl.  Result  follows  from  MatchI. 

case  Sub-CTrans.  We  have  A'  <  Ai  and  A\  <  A.  By  the  induction  hypothesis, 
matchArgim,  A\,  M )  =  A"  where  A"  <  A.  The  result  then  follows  from  Lemma  B.13. 

case  Sub-Extends.  We  have  A'  extends  A.  Suppose  B ’  m[Ar  x,B  x)  £  M.  By  MatchI, 
ar g 2  [matchArgim,  A1 ,  M))  =  A1,  which  gives  the  required  result.  Otherwise,  if 
A 1  extends  A  ,  we  must  show  that  there  exist  unique  k,  M'  such  that  matchArgim,  A',,  M) 
is  defined;  Match2  then  applies.  By  MatchI,  we  have  matchArgim,  A, M)  =  M'  and 
arg 2  [M')  =  A. 

Suppose  3A'j.  matchArgim,  A' j,M)  =  M"  and  argiiM")  =  B.  By  Lemma  B.6, 

C  mi(Bo@)B  x,B  x)  £  M.  By  Lemma  B.9,  A'.  <  B  so  therefore  A'  <  B.  By  T-Method, 
3D  f  Object.  A  <  D  and  B  <  D.  However,  this  means  that  a  diamond  results,  which  is 
impossible  (Lemma  B.8).  Therefore,  there  exists  a  unique  k  where  matchArgim,  A',  M )  = 
Mi.  By  Lemma  B.16,  this  value  is  unique. 


□ 

Lemma  B.18.  If  dispatchim,  C,A)  =  M  and  arg j  (M)  =  A'  then  mtypeim,  C)  =  [A",  B)  -*  B  where 
A'  <  A". 

Proof.  By  induction  on  dispatch. 

case  DispatchI.  We  have  class  •  •  •{  C  f;K  M}.  By  Lemma  B.6,  B  mi{B'@)A!  x,Bx)e  M.  Either 
(1)  x  has  type  B'@A '  or  it  has  type  A'.  In  case  (1),  by  T-Multi-Method,  mtypeim,  C)  = 
[B',B]  — ►  B,  where  A'  <  B' .  In  case  (2),  the  result  follows  from  MTypeI. 

case  Dispatch2.  We  have  dispatchim,  D ,  A)  =  M,  arg (M)  =  A'  and  C  extends  D.  By  the  induc¬ 
tion  hypothesis,  mtypeim,  D)  =  [A" ,B)  —  B,  where  A'  <  A".  The  result  then  follows  from 
MType2. 
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□ 


Lemma  B.19.  If  methodDeffn,  C,  A),  then  mtypefn,  C )  =  {B0,  B)  — >•  B,  where  A  <  B0. 

Proof.  By  induction  on  methodDeffn,  C,  A) . 

case  MethodDefI.  class  C-  ••{  C  f;K  M} 

There  are  two  possible  cases: 

(1)  B  m{A  x,B)  e  M.  Result  follows  from  MTypeI. 

(2)  B  m(B'@A  x,B )  e  M.  By  T-Multi-Method,  A  <  B'  and  mtype{m,C )  =  [B',B)  —>  B, 
which  is  the  required  result. 

case  MethodDef2.  By  the  induction  hypothesis,  mtype(m,  D /J  =  [Bq,B)  — *  B,  where  A  <  Bq 
and  C  extends  D]c.  The  result  then  follows  from  MType2. 


□ 


Lemma  B.  20.  If  matchArg{m,  D,  M)  =  M0,  and  argfMo )  =  B'  then  methodDef{m,C,B'). 
Proof.  By  induction  on  matchArgfn,  D,  M) . 

case  MatchArgI.  Result  follows  from  MethodDefI. 
case  MatchArg2.  Result  follows  from  induction  hypothesis. 


□ 


Lemma  B. 21.  If  dispatch{m,C,D)  =  M0  and  arg1(M0 )  =  B',  then  methodDef{m,C,B'). 

Proof.  By  induction  on  dispatchim,  C,  D) . 

case  DispatchI.  We  have  matchArg{m, D, M)  =  B0  m[B'x,B  x),  where  class  C---{C  f)K  M }. 
The  result  then  follows  from  Lemma  B.20. 

case  Dispatch2.  We  have  ME  =  {M/  |  dispatch{m,Ei,D)}  and  matchArg{m,D,ME)  = 
B0  m{B' x,B  x),  where  C  extends  E.  By  the  induction  hypothesis,  methodDef{m, Eit B')  = 
E'.}  for  some  E't  where  Ei  <  E'r  The  result  then  follows  from  MethodDef2  and  the  transi¬ 
tivity  of  subclassing. 


□ 


Lemma  B.22.  If  mtypefn,  C)  =  (Object,  B)  — >■  B  and  methodDefim,  C,  A),  then  A  =  Object. 
Proof.  By  induction  on  the  methodDef  derivation. 
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case  MethodDefI.  class  C---{C  f;K  M} 

There  are  two  possible  cases: 

(1)  B  m[A  x,B )  £  M.  By  inversion  on  mtype  and  the  uniqueness  of  mtype  (Lemma  B.3), 
A  =  Object. 

(2)  B  m{B'@A  x,B)  £  M.  By  the  uniqueness  of  mtype  (Lemma  B.3),  and  premise  (6)  of 
T-Multi-Method,  B'  =  Object.  But,  by  premise  (3),  B1  ^  Object,  so  this  case  is  impossible. 

case  MethodDef2.  We  have  methodDef{m,Dk,A),  where  C  extends  D^.  By  Lemma  B.19, 
mtype{m,D]c )  =  {B0,B  )  — *  B' .  By  the  uniqueness  of  mtype  (Lemma  B.3),  B  =  B,  B  =  B' , 
and  Bo  =  Object.  The  result  then  follows  from  the  induction  hypothesis. 


□ 


Lemma  B.23.  If  we  have  the  following: 

1.  class  C{  C  f;K  M}  extends  D\,D2 

2.  m  £  M 

3.  dispatch{m,Di,E )  =  M\  and  dispatch[m,  D2,  E)  =  M2 

4.  arg 7  (Mi)  =  Ai  and  arg j  (M2)  =  A2 
then  Ai  ^  A2  and  (Ai  <  A2  or  A2  <  Ai). 

Proof.  By  Lemma  B.10,  E  <  A\  and  E  <  A2.  By  Lemma  B.18,  mtype(m,D i)  =  {B0,B)  — *  B  and 
mtype(m,D2 )  =  {B'Q,B)  -*  B'  where  Ai  <  B0  and  A2  <  Bf  By  Lemma  B.3,  B0  =  B'0,  so  A\,  A2  <  B0. 

By  Lemma  B.21,  we  have  methodDefim, D±,  Af  and  methodDef{m,D2,A2).  Suppose  Ai  = 
A2.  By  T-Class,  C'  m{(A'@)Co  x,  C  x)  e  M,  which  is  a  contradiction. 

We  can  use  the  no-diamond  property  to  prove  the  second  conjunct  of  the  result, 
once  we  have  shown  that  B0  f  Object.  By  Lemma  B.21,  methodDef{m,D\,Ai)  and 
methodDefim, D2,  A2).  Then  mtype{m,D\ )  =  (Object, B)  —  B  and  mtype{m,D2)  =  (Object, B  )  — ► 
B'.  By  Lemma  B.22,  A\  =  A2  -  Object,  which  contradicts  the  result  proved  above  that  A\  f  A2. 

Finally,  by  Lemma  B.8,  since  B0  Object,  either  A\  <  A2  or  A2<  A\,  which  completes  the 
proof.  □ 

Lemma  B.24.  If  D  ::  mtype{m,C )  =  (B0,B)  — *  B  and  T>  does  not  contain  the  rule  MType3,  and 
Br  <  B0,  then  dispatch{m,  C,  B')  =  M  where  arg \  (M)  =  B"  and  B"  <  B0. 

Proof.  By  induction  on  T). 

case  MTypeI.  We  have  class  C---{C  f;K  M}  and  B  m{B0  x,B  x)  £  M.  By  Lemma  B.17, 
matchArgim,  B' ,  M)  =  M\  where  argfMf)  =  B"  and  B"  <  Bo.  The  result  then  follows  from 
Dispatch  1. 

case  MType2.  class  C  extends  D  {  C  f]K  M}  m£M  ::  mtype(m,Dk)  =  {B0,B)  -*•  B 

By  the  induction  hypothesis,  dispatch{m,Dic,  B')  =  M/0  where  arg i  [Mf]  -  and  A/c  <  B0. 

Let  Md  =  {Mi  |  dispatch{m,Di,B')}.  It  suffices  to  show  that 

3  unique  M" .  matchArgim,  B' ,Md)  =  M";  the  rule  Dispatch2  then  applies. 
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Let  Ai  =  argiiMi).  By  Lemma  B.23,  forall  i  f  j,  At  f  Aj  and  either  A[  <  Aj  or  Aj  <  At.  The 
result  then  follows  from  Lemma  B.14. 


□ 

Lemma  B.25.  If  D  ::  mtype{m,  D)  =  B  — *■  B  and  C  <:  D  and  T  I-  new  C(e) :  C,  then  there  exist  D' 
and  T>'  such  that  C  <  D'  and  T>' ::  mtype{m,D ')  =  B  — *  B,  where  T>'  does  not  contain  the  rule 
MType3. 

Proof.  By  induction  on  the  mtype  derivation. 

case  MType  1.  We  observe  that  T>  does  not  contain  the  rule  MType4.  There  are  two  possibilities: 
either  C  <  D,  in  which  case  let  T>'  =  D,  or  C  ^  D.  In  the  latter  case,  by  Lemma  B.5,  3E  < 
D.  C  requires  E.  But,  this  is  impossible;  by  inversion  on  T-New,  C  requires  •. 

case  MType2.  We  have  D  extends  D ^  where  ::  mtype{m,Dic)  =  B  — <•  B.  The  result  then  fol¬ 

lows  from  the  induction  hypothesis  and  MType2. 

case  MType3.  Similar  to  above. 


□ 

Lemma  B.26.  If  C  <  D  and  D  ::  mtype{m,D)  =  B  -+  B  does  not  contain  the  rule  MType3,  then 

there  exists  T>' ::  mtype(m,  C)  =  B  -+  B  that  does  not  contain  the  rule  MType3. 

Proof.  Straightforward  induction  on  C  <  D.  □ 

Lemma  B.27.  If  mtype{m,C )  =  (B0,B)  — ►  B  and  T  LnewC(e)  :  C,  and  B'  <  B0,  then 

mbodyim,  C,  B')  =  x.e0,  for  some  x  and  eo . 

Proof.  By  case  analysis  on  the  derivation  of  mtype. 

case  MTypeI.  By  Lemma  B.17,  matchArgfn, B' , M)  is  defined,  where  M  are  the  methods  of 
C.  By  Dispatch  1,  dispatch{m,  C,B')  is  defined,  which  implies  that  mbodyim,  C,B')  is  also 
defined. 

case  MType2.  We  have  mtypeimyDf)  =  (Bq,B)  — *  B,  where  C  extends  D^.  By  Lemmas  B.25  and 
B.26,  there  exists  V  ::  mtype{m,C )  =  (B0,B)  — ►  B  that  does  not  contain  rule  MType3.  By 
Lemma  B.24,  dispatch{m,C,B')  is  defined,  which  implies  that  mbody(m,C,B')  is  also  de¬ 
fined. 

case  MType3.  Vacuous;  by  inversion  of  T-New,  C  requires  •. 


□ 


Theorem  B.l  (Progress).  If  •  I -  e  :  C  then  either  e  is  a  value  or  there  is  an  e'  with  e  ■ — ►  e' . 
Proof.  By  induction  one:  C. 
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case  T-Var.  Vacuous. 


case  T-Field.  e  =  e0.fi 

We  have  fie  Ids  (Co)  =  C  f.  By  the  induction  hypothesis,  either  e0  is  a  value  or  it  evaluates  to 
some  e'{).  In  the  first  case,  the  rule  T-Field1  applies.  In  the  second  case,  the  rule  E-Field2 
applies. 

case  T-Invk.  e-e0.m(e)  e:C  C  <:D 

By  the  induction  hypothesis,  either  e0  is  a  value  or  it  evaluates  to  some  e'Q.  If  it  evaluates, 
then  the  rule  E-Invk-Recv  applies.  If  it  is  a  value,  then  either  the  arguments  e  evaluate  or 
they  are  values.  In  the  first  case,  E-Invk-Arg  applies. 

Otherwise,  by  assumption,  mtype{m,  Co)  =  D  —*  D  and  eo  :  Co  and  e\ :  C\  where  C\  <:  D\. 
By  inversion  on  T-New,  we  have  eo  =  new  Co(e'0)  and  e\  =  new  C\  (e[)  and  C\  requires  •.  By 
Lemma  B.4,  Ci  <  D\.  By  Lemma  B.27,  mbody{m,Co,C\)  is  defined;  the  rule  E-Invk  then 
applies. 

case  T-Super-Invk.  e  =  e0.D. super.  m(e) 

By  the  induction  hypothesis,  either  e0  is  a  value  or  it  evaluates  to  some  e[y  If  it  evalu¬ 
ates,  then  the  rule  E-Invk-Super-Recv  applies.  If  it  is  a  value,  then  either  the  arguments  e 
evaluate  or  they  are  values.  In  the  first  case,  E-  Super- Invk-Arg  applies. 

Otherwise,  by  inversion  on  T-New  we  have  e0  =  newCo(e)  and  e\  -  new  C]  (e\)  and 
Ci  requires  •.  By  assumption,  mtype{m,D )  =  D  —  C.  Since  Ci  <:  D\  by  Lemma  B.4, 
Ci  <  D\.  Let  E  =  super{C,D).  By  the  definition  of  super,  we  have  E  <  D.  By  Lemma  B.l, 
mtype[m,E)  =  D  — ►  C.  By  Lemma  B.27,  mbody[m,E,C\ )  is  defined.  The  rule  E-Super-Invk 
then  applies. 

case  T-New.  e=new  C(e) 

By  the  induction  hypothesis,  either  e  evaluates  or  it  is  a  value.  If  it  evaluates,  the  rule 
E-New-Arg  applies.  Otherwise,  the  expression  itself  is  a  value. 


□ 


B.3  Preservation  Lemmas  and  Proof 

Lemma  B.28  (Substitution).  If  T,  x  :  C  h  e  :  D  and  T  L  d  :  c'  where  c'  <:  C  then  T  h  [d/x]  e  :  D' 
for  some  D 1  <  :  D. 

Proof.  Similar  to  proof  of  FJ,  using  Lemma  B.2  for  the  case  of  method  invocation.  □ 

Lemma  B. 29  (Weakening).  If  T,x :  C,V  h  e :  B  then  for  C'  <:  C  and  B'  <:  B,T,x:  C’ ,T'  he:  B'. 

Proof.  Straightforward  induction  on  typing  derivations.  □ 

Lemma  B.30.  If  dispatch{m,C,D)  =  x.e0  then  there  exists  a  unique  B  —  B  such  that 
mtype{m,  O-B-^-B. 
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Proof.  By  induction  on  the  derivation  of  dispatch. 

case  DispatchI.  By  Lemma  B.6,  m  e  M.  The  result  then  follows  from  MTypeI. 

case  Dispatch2.  By  Lemma  B.6,  M"  £  Me-  By  definition,  M"  =  dispalchim,  E/.,  D)  where 
C  extends  E^.  By  the  induction  hypothesis,  mtype{m,Eic )  =  B  — *■  B.  By  MType2, 
mtypefn,  C)  =  B  —>  B  and  by  Lemma  B.3,  this  value  is  unique. 


□ 

Lemma  B.31.  If  dispatch{m,C,D )  =  M'  where  M'  =  E  m(E0  x,E  x)  { return  e;}  and 

mtype{m,  C)  =  [B0,B]  —  B  then  there  exists  some  B'  <:  B  such  that  x :  B0,x :  £,this :  C  b  e :  B' . 

Proof.  By  induction  on  the  definition  of  dispatchfn,  C,  D ) . 

case  DispatchI.  By  Lemma  B.6,  M'  =  D0  m[(D@)D'  x,D  x)  and  M'  e  M,  where  D'  <  D.  By 
inversion  on  T-Method  and  T-Multi-Method,  the  result  follows. 

case  Dispatch2.  By  Lemma  B.6,  M'  e  Me-  By  definition,  M'  =  dispalch{m}  E^,  D)  where 
C  extends  E^.  By  Lemma  B.30,  mtypeim^f)  =  C  -*■  C',  for  some  unique  C  C' . 
Since  3M' .matchArg{m,D,M)  =  M' ,  by  Lemma  B.7,  Co  m{{C@)D'  x,C  x)  £  M' ,  where 
D  <  D' .  So,  by  MType2,  mtype{m,C )  =  rntypeirriyEf).  Since  the  result  of  mtype  is 
unique  (Lemma  B.3),  we  have  B  =  C  and  B  =  C' .  Applying  the  induction  hypothesis  to 
dispatchim,  Ejc,  D)  and  mtypeim,  E/-)  yields  the  required  result. 


□ 


Theorem  B.2  (Preservation).  If  T  \-  e:C  and  e  ■ — *  e' ,  then  T  h  e' :  C'  for  some  C'  <:  C. 
Proof.  By  induction  on  derivation  of  e  > — ►  e' . 

case  E-Field. 

e  =  (newC0(e))./;- 

e'  =  et  _ 

fieldsiCf)  =  D  f 
D,  =  C 

By  the  rule  T- Field,  T  I-  new  Co(e) :  Co  Co  <:  Co. 

By  T-New,  T  I- e:  C  C  <:  D  Co-Co- 

By  transitivity  of  sub  typing,  et :  Dit  which  is  the  required  result. 

case  E-Invk. 

e  =  (new  C0(e)).m(newD(e'),d) 

e'  =  [new  D(er)lx,  dlx,  new  Co (e) /this]  e0 

mbody(m,Co,D )  =  (x,x).e0 

By  T-Invk  and  T-New: 

T  I-  new  Co(e) :  Co 
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r  b  new  D(e') :  D  D<:D0 
T\~d:B  B<:D 
mtype{m,  Co)  =  {D0,D)  —  C 

From  the  definition  of  mbody,  we  have  dispatchim,  Co,  D)  =  E  m{E0  x,  E  x)  { return  e;}. 
By  Lemma  B.31,  there  exists  some  C'  <:  C  such  that  x  :  D0,x  :  D, this  :  Co  L  e0  :  C' .  By 
LemmaB.28,  •  h[newD(e')/i,  d/x,  new  C0(e) /this]  e0  :  C",  for  some  C"  <:C'.  By  the  tran¬ 
sitivity  of  sub  typing,  C"  <:  C,  which  is  the  required  result. 

case  E-Super-Invk. 

e  =  (new  C0(e)).B.super.m(new  D(e'),d ) 

By  T- Super- Invk  and  T-New: 
class  C0  requires  B,E 
class  Co  requires  • 

This  is  a  contradiction,  therefore  this  case  is  vacuous  (dynamically-dispatched  super  calls 
can  only  be  applied  to  classes  with  a  non-empty  requires  clause). 

The  cases  for  the  congruence  rules  are  straightforward. 

□ 
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